| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Antonin Houska <ah(at)cybertec(dot)at> |
| Subject: | Re: Possible premature SNAPBUILD_CONSISTENT with DB-specific running_xacts |
| Date: | 2026-04-20 06:04:17 |
| Message-ID: | CAA4eK1+Y7qwvzSjeY=KWWLHw3wQNxD7ebr5FoWTuBOYpRGhc3A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Apr 20, 2026 at 12:29 AM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
>
> 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.
>
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-04-20 06:06:27 | [PATCH] Reject ENCODING option for COPY TO FORMAT JSON |
| Previous Message | Nishant Sharma | 2026-04-20 06:01:10 | Re: [BUG] CRASH: ECPGprepared_statement() and ECPGdeallocate_all() when connection is NULL |