RE: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT - Mailing list pgsql-hackers

From ocean_li_996
Subject RE: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT
Date
Msg-id 7f9e2358.9b73.19c05f3296f.Coremail.ocean_li_996@163.com
Whole thread Raw
In response to RE: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
Hi Hayato,

At 2026-01-27 10:17:26, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com> wrote:
>Sorry, can you evaluate bit more why the 0003 patch is enough for the fix? E.g.,
>apart from 0001, 0003 adds invalidation message to the transaction (or immediately
>invalidate) even if we do not have the consistent snapshot yet.

Yeah. IIUC, the 0003 patch can fix this issue.

The 0003 patch involves the least amount of code changes, but the trade‑off is that
it adds extra computation and memory usage, which may affect efficiency. This is because,
during the transition from SNAPBUILD_BUILDING_SNAPSHOT to SNAPBUILD_FULL_SNAPSHOT, useless
XIDs (see the definition of useless XIDs in the 0004 patch) will be added to the reorder buffer.

The regular changes of these useless‑XID transactions will not be added to the reorder buffer
(see SnapBuildProcessChange). Invalidation messages with a useless XID will be added to the
reorder buffer, but will not be processed, because the transaction does not yet have a base
snapshot (see ReorderBufferForget). As for invalidation messages without an XID, they will still
be executed, but this will not cause correctness issues, since we are still in a state where
changes cannot be decoded.

Regards
Haiyang Li


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: pgsql: Prevent invalidation of newly synced replication slots.
Next
From: ocean_li_996
Date:
Subject: Re:RE: Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT