agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@kurilemu.de>
Cc: Rui Zhao <zhaorui126@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Subject: Re: Race conditions in logical decoding
Date: Fri, 18 Sep 2026 17:23:29 +0200
Message-ID: <12834.1789745009@localhost> (raw)
In-Reply-To: <aq1Jy9aVF-lIhKwe@alvherre.pgsql>
References: <aq1Jy9aVF-lIhKwe@alvherre.pgsql>
Alvaro Herrera <alvherre@kurilemu.de> wrote:
> On 2026-Sep-18, Antonin Houska wrote:
>
> > Maybe I miss the point, but what's wrong about modifying the existing loop
> > that inverts the meaning of the ->xip array
> >
> > /*
> > * snapbuild.c builds transactions in an "inverted" manner, which means it
> > * stores committed transactions in ->xip, not ones in progress. Build a
> > * classical snapshot by marking all non-committed transactions as
> > * in-progress. This can be expensive.
> > */
> > for (xid = snap->xmin; NormalTransactionIdPrecedes(xid, snap->xmax);)
> > {
> > ...
> > }
> >
> > by calling XactLockTableWait() for each XID we find in the array (i.e. each
> > committed transaction)?
>
> Ah, you mean something like the attached quick POC? This does pass the
> two tests that Rui wrote, also attached. (I didn't test Zhijie's, which
> AFAICT is written to pass with the bug and fail without it.)
Yes, I mean checking if those transactions have really ended.
Regarding [1], perhaps the idea is to avoid calling XactLockTableWait() if the
transaction is no longer in procarray. I'm not sure it's a problem to call
that function (possibly many times) for transactions that are no longer
running. (GetRunningTransactionData() is not free either.)
And regarding the deadlock with synchronous replica, my understanding is that
we avoid it by waiting in SnapBuildInitialSnapshot() instead of in
SnapBuildBuildSnapshot().
[1] https://www.postgresql.org/message-id/CAHWVJhHXyLtS-8mdL9WhEWfsERb%3DFN7JdPD0GYAXgTmCnqbYGw%40mail.g...
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
view thread (38+ messages) latest in thread
Message-ID: <12834.1789745009@localhost>
Permalink: ../12834.1789745009@localhost/
Also on: postgresql.org/message-id/12834.1789745009@localhost
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: ah@cybertec.at, alvherre@kurilemu.de, zhaorui126@gmail.com, andres@anarazel.de, mihailnikalayeu@gmail.com
Subject: Re: Race conditions in logical decoding
In-Reply-To: <12834.1789745009@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox