RE: Race conditions in logical decoding

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: "alvherre(at)kurilemu(dot)de" <alvherre(at)kurilemu(dot)de>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: RE: Race conditions in logical decoding
Date: 2026-09-17 10:10:01
Message-ID: TY4PR01MB1771891DD55D9ECB5B01B45A794B82@TY4PR01MB17718.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thursday, September 17, 2026 5:53 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> > On Wednesday, September 9, 2026 6:20 PM Álvaro Herrera
> <alvherre(at)kurilemu(dot)de> wrote:
> > > OK. TBH I'm somewhat unease about this inconsistency; I wondered
> > > about doing the CLOG-based test only in sync replication and using
> > > XidIsInProgress otherwise, but didn't really try (which is to say:
> > > I'm not even sure if it's _possible_ at all.)
> >
> > I experimented with this a bit and confirmed that the inconsistency
> > exists, though it doesn't affect REPACK (CONCURRENTLY), the command
> > takes an exclusive 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 snapshot, as shown in the attachment (generated with AI
> assistance).
>
> ...
> > --- /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 other # 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 situation?

I'm personally not comfortable with the fact that an MVCC snapshot could ever
see changes from a transaction that is still considered in progress from
PGPROC's perspective. This situation can only arise when using a snapshot
exported by logical decoding. IIUC, any other normal MVCC snapshot follows the
same rule: it cannot see changes whose PGPROC entries have not been cleaned,
regardless of when the snapshot is created or used, as long as the PGPROC xid
has not been cleaned. (I may be missing some cases, please correct me if so.)

> What I'd consider a problem would be a single backend (and single
> transaction) seeing inconsistent data.

Best Regards,
Zhijie Hou

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Florin Irion 2026-09-17 10:10:13 Re: Proposal: Supporting URI SAN in Certificate Authentication
Previous Message Yilin Zhang 2026-09-17 09:56:11 Re: Reducing relcache memory usage: deduping index shapes