RE: Race conditions in logical decoding

Hi,

On Wednesday, September 9, 2026 6:20 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> On 2026-Aug-22, Zhijie Hou (Fujitsu) wrote:
> >
> > 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 which
> 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 replication processes.
>
> 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).

>
> > However, for cases where the snapshot is exported, would it be
> > possible to additionally wait for it in SnapBuildInitialSnapshot()
> > (which is used only by CREATE_REPLICATION_SLOT and REPACK)? Since
> that
> > runs before START_REPLICATION, the process isn't streaming or feeding
> > any subscriber, so I believe the deadlock wouldn't occur there. (I
> > think that the walsender executing CREATE_REPLICATION_SLOT shouldn't
> > be added to sync_standby_names, otherwise building the initial
> > snapshot itself would already have a deadlock risk via
> > SnapBuildWaitSnapshot->XactLockTableWait.)
>
> Yeah, we could do that.
>
> Do you want to try and write a patch?

I see that Rui Zhao has shared a patch based on this approach [1]. The email is
lengthy, but the core idea is to perform the wait inside
SnapBuildInitialSnapshot().

[1] https://www.postgresql.org/message-id/CAHWVJhHXyLtS-8mdL9WhEWfsERb%3DFN7JdPD0GYAXgTmCnqbYGw%40mail.gmail.com

Best Regards,
Zhijie Hou