From: Antonin Houska <ah@cybertec.at>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
cc: alvherre@kurilemu.de,
    "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
    Mihail Nikalayeu <mihailnikalayeu@gmail.com>,
    Andres Freund <andres@anarazel.de>
Subject: Re: Race conditions in logical decoding
In-reply-to: 
 <TY4PR01MB1771857EBA55C85BC365AC5E594B92@TY4PR01MB17718.jpnprd01.prod.outlook.com>
References: 
 <TY4PR01MB177187B7CB7BE12F70F806BE494A22@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <aqEtEZP-7kpX3_Ov@alvherre.pgsql>
 <TY4PR01MB1771857EBA55C85BC365AC5E594B92@TY4PR01MB17718.jpnprd01.prod.outlook.com>
Comments: In-reply-to "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
   message dated "Wed, 16 Sep 2026 07:59:58 -0000."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Sep 2026 11:52:42 +0200
Message-ID: <14388.1789638762@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/14388.1789638762%40localhost>
Precedence: bulk

Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:

> On Wednesday, September 9, 2026 6:20 PM =C3=81lvaro Herrera <alvherre@kur=
ilemu.de> wrote:
> > On 2026-Aug-22, Zhijie Hou (Fujitsu) wrote:
> > >=20
> > > Besides, just to confirm one note: IIUC, for exported snapshots by
> > > logicalrep, a transaction could be treated as committed while still in
> > > PGPROC, while concurrent MVCC snapshots still see it as in progress w=
hich
> > looks inconsistent.
> > > I understand that waiting for ProcArray removal in the general case
> > > could deadlock against synchronous replication, so it's probably
> > > acceptable to leave it unchanged for internal usage in active replica=
tion processes.
> >=20
> > OK.  TBH I'm somewhat unease about this inconsistency; I wondered about
> > doing the CLOG-based test only in sync replication and using XidIsInPro=
gress
> > otherwise, but didn't really try (which is to say: I'm not even sure if=
 it's
> > _possible_ at all.)
>=20
> I experimented with this a bit and confirmed that the inconsistency exist=
s,
> though it doesn't affect REPACK (CONCURRENTLY), the command takes an excl=
usive
> lock on the table when switching the old and new heap, which forces any
> concurrent transactions on that table to finish first. However, the
> inconsistency can be observed if a user directly uses the exported snapsh=
ot, as
> shown in the attachment (generated with AI assistance).

...

> diff --git a/src/test/recovery/t/058_exported_snapshot_pgproc_window.pl b=
/src/test/recovery/t/058_exported_snapshot_pgproc_window.pl
> new file mode 100644
> index 00000000000..4b6d8dd8353
> --- /dev/null
> +++ b/src/test/recovery/t/058_exported_snapshot_pgproc_window.pl
> @@ -0,0 +1,293 @@
> +# Copyright (c) 2026, PostgreSQL Global Development Group
> +#
> +# Test that a snapshot exported by CREATE_REPLICATION_SLOT ... (SNAPSHOT
> +# 'export') can treat a transaction as committed while that transaction =
is
> +# still in the procarray, so that concurrent MVCC snapshots taken by oth=
er
> +# backends still see it as in progress.

As far as I understand, what you demonstrate here is that different backends
can have a different view of the database. Isn't that pretty common situati=
on?

What I'd consider a problem would be a single backend (and single transacti=
on)
seeing inconsistent data.

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