Fix snapshot used in logical replication index lookup
authorHeikki Linnakangas <[email protected]>
Mon, 10 Mar 2025 15:07:38 +0000 (17:07 +0200)
committerHeikki Linnakangas <[email protected]>
Mon, 10 Mar 2025 15:08:05 +0000 (17:08 +0200)
The function calls GetLatestSnapshot() to acquire a fresh snapshot,
makes it active, and was meant to pass it to table_tuple_lock(), but
instead called GetLatestSnapshot() again to acquire yet another
snapshot. It was harmless because the heap AM and all other known
table AMs ignore the 'snapshot' argument anyway, but let's be tidy.

In the long run, this perhaps should be redesigned so that snapshot
was not needed in the first place. The table AM API uses TID +
snapshot as the unique identifier for the row version, which is
questionable when the row came from an index scan with a Dirty
snapshot. You might lock a different row version when you use a
different snapshot in the table_tuple_lock() call (a fresh MVCC
snapshot) than in the index scan (DirtySnapshot). However, in the heap
AM and other AMs where the TID alone identifies the row version, it
doesn't matter. So for now, just fix the obvious albeit harmless bug.

This has been wrong ever since the table AM API was introduced in
commit 5db6df0c01, so backpatch to all supported versions.

Discussion: https://www.postgresql.org/message-id/83d243d6-ad8d-4307-8b51-2ee5844f6230@iki.fi
Backpatch-through: 13

src/backend/executor/execReplication.c

index 3ecb7efe365ae17685c065500a9f959ea2061c35..6538e6b9c13dd95402f163a012a78c537dbf2a84 100644 (file)
@@ -175,7 +175,7 @@ retry:
 
        PushActiveSnapshot(GetLatestSnapshot());
 
-       res = table_tuple_lock(rel, &(outslot->tts_tid), GetLatestSnapshot(),
+       res = table_tuple_lock(rel, &(outslot->tts_tid), GetActiveSnapshot(),
                               outslot,
                               GetCurrentCommandId(false),
                               lockmode,