Bug in logical decoding with DDL and subtransactions - #418
Open
pg-hub-mirror[bot] wants to merge 1 commit into
Open
pg-hub-mirror[bot] wants to merge 1 commit into
pg-hub-mirror[bot] wants to merge 1 commit into
Conversation
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
Author
|
Earlier design discussion: Discussion #390 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pgsql-hackersME0P300MB0953C39C7B699C13909A2036C6872@ME0P300MB0953.AUSP300.PROD.OUTLOOK.COMPatch 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