Subject: Possible premature SNAPBUILD_CONSISTENT with DB-specific running_xacts

From: SATYANARAYANA NARLAPURAM <[email-masked]>
Date: Sun, 19 Apr 2026 11:58:46 -0700

Hi hackers,

A cluster-wide decoder must never have its snapshot-builder state changed
by a database-specific running_xacts record. Adding a check to return it
early.
I think otherwise a cluster wide decoder can potentially go to
SNAPSHOT_CONSISTENT state immediately even though transactions older
than nextXid are still in progress on a different DB (not tracked by
running_xact
record). This race is now possible with cluster wide decoders and Repack
concurrently run.

Attached a patch to fix this. Thoughts?

Thanks
Satya

---

From: Amit Kapila <[email-masked]>
Date: Mon, 20 Apr 2026 11:34:17 +0530

On Mon, Apr 20, 2026 at 12:29 AM SATYANARAYANA NARLAPURAM
<[email-masked]> wrote:
> by a database-specific running_xacts record. Adding a check to return it early.
> than nextXid are still in progress on a different DB (not tracked by running_xact

I think this has been discussed previously, see [1]. As per my
understanding, we are not in agreement for the need of this
db-specific handling in the snapbuilder, see [2][3]. So, adding more
improvements/fixes on top of it doesn't sound advisable.

[1] - https://www.postgresql.org/message-id/CAA4eK1KWDbBk4FgbbWdivQLrPPzR4zgvfnHK4WjWC78rbuRVbg%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/cdgw4sbbfcgk6du3iv54r2dgiy4tfywoklbotlmj4irxavdcr3%40glxfw5jj277q
[3] - https://www.postgresql.org/message-id/pveffyxhnuurhb44uzqlwo3rkyzorkfh2rot7uwzlf2axhfvbp%407nrs2omysxkc

-- 
With Regards,
Amit Kapila.