From: Antonin Houska <ah@cybertec.at>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org, alvherre@kurilemu.de
Subject: Re: Race conditions in logical decoding
In-reply-to: <5k2dfckyp6zv2fiovosvtbya5onvplgviz5n4kdamxupff4vi2@yytzfnwr2ox7>
References: <85833.1768840165@localhost> <62335.1768897833@localhost> <5k2dfckyp6zv2fiovosvtbya5onvplgviz5n4kdamxupff4vi2@yytzfnwr2ox7>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
   message dated "Tue, 20 Jan 2026 12:50:13 -0500."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5697.1769155332.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Jan 2026 09:02:12 +0100
Message-ID: <5698.1769155332@localhost>
Archived-At: <https://www.postgresql.org/message-id/5698.1769155332%40localhost>
Precedence: bulk

Andres Freund <andres@anarazel.de> wrote:

> > Attached here is what I consider a possible fix - simply wait for the =
CLOG
> > update before building a new snapshot.
> =

> I don't think that's enough - during non-timetravel visibility semantics=
, you
> can only look at the clog if the transaction isn't marked as in-progress=
 in
> the procarray.  ISTM that we need to do that here too?

I understand that CLOG must be up-to-date by the time the snapshot is used=
 for
visibility checks, but I think that - from the snapshot user POV - what
matters is "snapshot->xip vs CLOG" rather than "procarray vs CLOG".

For procarray-based snapshots, this consistency is ensured by 1) not remov=
ing
the XID from procarray until the status is set in CLOG and 2) getting the =
list
of running transactions from procarray. Thus if an MVCC snapshot does not =
have
particular XID in its "xip" array, it implies that it's no longer in proca=
rray
and therefore it's been marked in CLOG.

As for logical decoding based snapshots (whether HISTORIC_MVCC or those
converted eventually to regular MVCC), we currently do not check if CLOG i=
s
consistent with the transaction list in snapshot->xip. What I proposed is =
that
we enforce this consistency by checking CLOG (and possibly waiting) before=
 we
finalize the snapshot. Thus the snapshot user can safely assume that the
snapshot->xip array is consistent with CLOG, as if the snapshot was based =
on
procarray.

Or is there another issue with the CLOG itself? I thought about wraparound
(i.e. getting the XID status from a CLOG slot which is still being used by=
 old
transactions) but I wouldn't expect that (AFAICS, CLOG truncation takes pl=
ace
during XID freezing). Concurrent access to the slot should neither be a
problem since only a single byte (which is atomic) needs to be fetched dur=
ing
the XID status check.

Another hypothetical problem that occurs to me is memory access ordering,
i.e. one backend creates and exports the snapshot and another one imports =
it
before it can see the CLOG update. It's hard to imagine though.

Or are there other concerns?

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com