public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Fix snapshot used in logical replication index lookup
6+ messages / 1 participants
[nested] [flat]
* pgsql: Fix snapshot used in logical replication index lookup
@ 2025-03-10 15:12 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2025-03-10 15:12 UTC (permalink / raw)
To: [email protected]
Fix snapshot used in logical replication index lookup
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/[email protected]
Backpatch-through: 13
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/2ef048855fdc770302a2c5897c6bbeef8af4ad62
Modified Files
--------------
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix snapshot used in logical replication index lookup
@ 2025-03-10 15:12 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2025-03-10 15:12 UTC (permalink / raw)
To: [email protected]
Fix snapshot used in logical replication index lookup
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/[email protected]
Backpatch-through: 13
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/23675031774c1644c32ff052a1c3e9fb87261023
Modified Files
--------------
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix snapshot used in logical replication index lookup
@ 2025-03-10 15:12 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2025-03-10 15:12 UTC (permalink / raw)
To: [email protected]
Fix snapshot used in logical replication index lookup
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/[email protected]
Backpatch-through: 13
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/9b3914f181658d7c7d4bad4d69a5152fcf3eb9e8
Modified Files
--------------
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix snapshot used in logical replication index lookup
@ 2025-03-10 15:12 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2025-03-10 15:12 UTC (permalink / raw)
To: [email protected]
Fix snapshot used in logical replication index lookup
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/[email protected]
Backpatch-through: 13
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/c1dd3a9443991244b7cfac407cdb23150e97b46a
Modified Files
--------------
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix snapshot used in logical replication index lookup
@ 2025-03-10 15:12 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2025-03-10 15:12 UTC (permalink / raw)
To: [email protected]
Fix snapshot used in logical replication index lookup
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/[email protected]
Backpatch-through: 13
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/50c5899922c3e5ee6c4df3cb3825255d09928edc
Modified Files
--------------
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix snapshot used in logical replication index lookup
@ 2025-03-10 15:12 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2025-03-10 15:12 UTC (permalink / raw)
To: [email protected]
Fix snapshot used in logical replication index lookup
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/[email protected]
Backpatch-through: 13
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/8171d2dae93d8463f2cbba0ce18e3f5c85cac096
Modified Files
--------------
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-03-10 15:12 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-03-10 15:12 pgsql: Fix snapshot used in logical replication index lookup Heikki Linnakangas <[email protected]>
2025-03-10 15:12 pgsql: Fix snapshot used in logical replication index lookup Heikki Linnakangas <[email protected]>
2025-03-10 15:12 pgsql: Fix snapshot used in logical replication index lookup Heikki Linnakangas <[email protected]>
2025-03-10 15:12 pgsql: Fix snapshot used in logical replication index lookup Heikki Linnakangas <[email protected]>
2025-03-10 15:12 pgsql: Fix snapshot used in logical replication index lookup Heikki Linnakangas <[email protected]>
2025-03-10 15:12 pgsql: Fix snapshot used in logical replication index lookup Heikki Linnakangas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox