]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix catalog lookup with the wrong snapshot during logical decoding.
authorAmit Kapila <akapila@postgresql.org>
Thu, 11 Aug 2022 04:15:04 +0000 (09:45 +0530)
committerAmit Kapila <akapila@postgresql.org>
Thu, 11 Aug 2022 04:15:04 +0000 (09:45 +0530)
commit68dcce247f1a13318613a0e27782b2ca21a4ceb7
tree9e1eb2e3074b0931797941cfe012a330254bba59
parent95bfadd4e83c17f1a31ab97eb2aba44a38c36324
Fix catalog lookup with the wrong snapshot during logical decoding.

Previously, we relied on HEAP2_NEW_CID records and XACT_INVALIDATION
records to know if the transaction has modified the catalog, and that
information is not serialized to snapshot. Therefore, after the restart,
if the logical decoding decodes only the commit record of the transaction
that has actually modified a catalog, we will miss adding its XID to the
snapshot. Thus, we will end up looking at catalogs with the wrong
snapshot.

To fix this problem, this changes the snapshot builder so that it
remembers the last-running-xacts list of the decoded RUNNING_XACTS record
after restoring the previously serialized snapshot. Then, we mark the
transaction as containing catalog changes if it's in the list of initial
running transactions and its commit record has XACT_XINFO_HAS_INVALS. To
avoid ABI breakage, we store the array of the initial running transactions
in the static variables InitialRunningXacts and NInitialRunningXacts,
instead of storing those in SnapBuild or ReorderBuffer.

This approach has a false positive; we could end up adding the transaction
that didn't change catalog to the snapshot since we cannot distinguish
whether the transaction has catalog changes only by checking the COMMIT
record. It doesn't have the information on which (sub) transaction has
catalog changes, and XACT_XINFO_HAS_INVALS doesn't necessarily indicate
that the transaction has catalog change. But that won't be a problem since
we use snapshot built during decoding only to read system catalogs.

On the master branch, we took a more future-proof approach by writing
catalog modifying transactions to the serialized snapshot which avoids the
above false positive. But we cannot backpatch it because of a change in
the SnapBuild.

Reported-by: Mike Oh
Author: Masahiko Sawada
Reviewed-by: Amit Kapila, Shi yu, Takamichi Osumi, Kyotaro Horiguchi, Bertrand Drouvot, Ahsan Hadi
Backpatch-through: 10
Discussion: https://postgr.es/m/81D0D8B0-E7C4-4999-B616-1E5004DBDCD2%40amazon.com
contrib/test_decoding/Makefile
contrib/test_decoding/expected/catalog_change_snapshot.out [new file with mode: 0644]
contrib/test_decoding/specs/catalog_change_snapshot.spec [new file with mode: 0644]
src/backend/replication/logical/decode.c
src/backend/replication/logical/snapbuild.c
src/include/replication/snapbuild.h