Skip to content

Bug in logical decoding with DDL and subtransactions - #418

Open
pg-hub-mirror[bot] wants to merge 1 commit into
masterfrom
pg-hub/mirror-patch-a29c41d6cf28792e
Open

pg-hub-mirror[bot] wants to merge 1 commit into
masterfrom
pg-hub/mirror-patch-a29c41d6cf28792e

Conversation

@pg-hub-mirror

@pg-hub-mirror pg-hub-mirror Bot commented Sep 18, 2026

Copy link
Copy Markdown

Read-only mirror. Reply and review on pgsql-hackers; activity here is not sent upstream.

  • Original author: Bingshuai Li <lucian1412(at)outlook(dot)com>
  • Mailing list: pgsql-hackers
  • Message-ID: ME0P300MB0953C39C7B699C13909A2036C6872@ME0P300MB0953.AUSP300.PROD.OUTLOOK.COM
  • Original email

Patch files:


Hi,
Housekeeping for the commitfest entry: CFBot picked up the
REL_14_STABLE back-branch version from my previous mail and now
reports "needs rebase" against master. Re-attaching the master
version of v4 (unchanged; still applies cleanly to current master
e1d8f81), so the entry points at the right patch again. The
branch versions from my previous mail are for the back branches
only.
Thanks,
Bingshuai Li

Tuplecid changes are always queued on the toplevel transaction, so
unlike regular changes they are not dropped when the subtransaction
that wrote them aborts.  The stale mappings corrupt
ReorderBufferBuildTupleCidHash() at commit time: if a later catalog
insert reuses the aborted subtransaction's line pointer (made
LP_UNUSED by on-access pruning or by vacuum), the fresh record
collides with the stale one with a different cmin, tripping the cmin
equality assertion; where nothing reuses the tid, a stale cmax makes
a still-live catalog tuple look deleted on historic snapshots.  On
non-assert builds there is no crash, but the stale mappings risk
misjudging historic catalog visibility, which could produce
incorrect decoding output.

Remove the aborted subtransaction's tuplecid entries in
ReorderBufferAbort() when the sub->top association is known.  The
association can be unknown in a decoding pass that started after the
subtransaction's first (toplevel-xid-bearing) WAL record, e.g. when
decoding restarted in the middle of the transaction: tuplecid
records are dispatched on the writing subtransaction without
establishing the association, and abort records never carry the
toplevel xid.  Skipping the cleanup in that case is safe because of
how a slot's restart point advances: SnapBuildProcessRunningXacts()
cannot move the restart point past the oldest in-progress
transaction, so any pass that output-decodes the toplevel commit
must have replayed the subtransaction's first record and therefore
knows the association.  Conversely, once the restart point has
advanced past that record, the commit has already been consumed by
an earlier pass and is skipped via SnapBuildXactNeedsSkip(), so any
stale tuplecid entries left behind are dropped along with the
transaction state and never reach ReorderBufferBuildTupleCidHash().

Add an isolation test for the restart shape: the transaction stays
open across checkpoints, the aborted subtransaction's catalog insert
is vacuumed away by another session so that the toplevel's later
insert deterministically reuses the same line pointer, and the final
get_changes both replays the transaction across a restart and
output-decodes its commit.  On unfixed assert builds the test dies
deterministically with the cmin assertion in
ReorderBufferBuildTupleCidHash(); with the fix it passes.  The
existing regression test keeps covering the continuous (no restart)
shape.

Bug: #19555
Reported-by: Alexander Kozhemyakin <a.kozhemyakin@postgrespro.ru>
Based-on-patch-by: Mark Dilger
Discussion: https://postgr.es/m/CAHgHdKu5e3XY5e90Tuaxq_R4WrKxSV734Q%2BLwo5y39Omp2A-Gg@mail.gmail.com
@pg-hub-mirror

pg-hub-mirror Bot commented Sep 18, 2026

Copy link
Copy Markdown
Author

Earlier design discussion: Discussion #390

@pg-hub-mirror pg-hub-mirror Bot added source:pgsql-hackers Mirrored from pgsql-hackers type:patch Mail thread contains a PostgreSQL patch area:sql SQL language or commands area:replication Physical or logical replication labels Sep 18, 2026
@pg-hub-mirror pg-hub-mirror Bot locked and limited conversation to collaborators Sep 18, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area:replication Physical or logical replication area:sql SQL language or commands source:pgsql-hackers Mirrored from pgsql-hackers type:patch Mail thread contains a PostgreSQL patch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant