Feedback-ID: ie3de48e3:Fastmail
Date: Thu, 24 Sep 2026 12:23:27 +0200
From: Alvaro Herrera <alvherre@kurilemu.de>
To: Rui Zhao <zhaorui126@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>, Andres Freund <andres@anarazel.de>,
	pgsql-hackers@lists.postgresql.org,
 Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Subject: Re: Race conditions in logical decoding
Message-ID: <arT5HxECyy5DYb0P@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAHWVJhHZhnwDMvs7Ev6W2DhMJypLYNn7xOxTeFAJucuty9h+_w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/arT5HxECyy5DYb0P%40alvherre.pgsql>
Precedence: bulk

On 2026-Sep-24, Rui Zhao wrote:

> Thanks. Going back to my original loop with the limit changed to
> running->xcnt makes sense.

OK, I have pushed this to all branches, including the test cases on
branches where they work.  Thanks all for the work on this issue!

I'm going to mark the two pg19 open items (!!) as done.

> On 2026-Sep-21 at 15:35 UTC, Alvaro Herrera wrote:
> > I think we should just go up to running->xcnt
> > only;
> 
> Yes, scanning the subxids was unnecessary. My previous explanation
> addressed overflow, but waiting for the parent covers the children in
> the non-overflow case too. A note on the top-level-first ordering in
> RunningTransactionsData would make that dependency explicit.

I didn't add this ... let's consider that as follow-on work, but we
don't need it to be backpatched.

> > maybe we should add
> > something in SnapBuildBuildSnapshot()
> 
> Agreed. The explanation of why historic snapshots need no wait for
> transactions to finish belongs there. The comment in
> SnapBuildInitialSnapshot() can then focus on why the conversion to a
> normal MVCC snapshot needs the wait.

Done that way -- I hope the explanations are clear.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/