Fix predicate-locking of HOT updated rows.
In serializable mode, heap_hot_search_buffer() incorrectly acquired a
predicate lock on the root tuple, not the returned tuple that satisfied
the visibility checks. As explained in README-SSI, the predicate lock does
not need to be copied or extended to other tuple versions, but for that to
work, the correct, visible, tuple version must be locked in the first
place.
The original SSI commit had this bug in it, but it was fixed back in 2013,
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months
later in commit b89e151054. Wising up from that, add a regression test
to cover this, so that it doesn't get reintroduced again. Also, move the
code that sets 't_self', so that it happens at the same time that the
other HeapTuple fields are set, to make it more clear that all the code in
the loop operate on the "current" tuple in the chain, not the root tuple.
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,
test case and some additional changes to the fix by Heikki Linnakangas.
Backpatch to all supported versions (9.4).
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de
2019-08-07 11:40:49 +02:00
|
|
|
Parsed test spec with 2 sessions
|
|
|
|
|
|
|
|
starting permutation: b1 b2 r1 r2 w1 w2 c1 c2
|
|
|
|
step b1: BEGIN ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
step b2: BEGIN ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
step r1: SELECT * FROM test WHERE i IN (5, 7)
|
2021-06-23 17:12:31 +02:00
|
|
|
i|t
|
|
|
|
-+----------------
|
|
|
|
5|apple
|
|
|
|
7|pear_hot_updated
|
|
|
|
(2 rows)
|
Fix predicate-locking of HOT updated rows.
In serializable mode, heap_hot_search_buffer() incorrectly acquired a
predicate lock on the root tuple, not the returned tuple that satisfied
the visibility checks. As explained in README-SSI, the predicate lock does
not need to be copied or extended to other tuple versions, but for that to
work, the correct, visible, tuple version must be locked in the first
place.
The original SSI commit had this bug in it, but it was fixed back in 2013,
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months
later in commit b89e151054. Wising up from that, add a regression test
to cover this, so that it doesn't get reintroduced again. Also, move the
code that sets 't_self', so that it happens at the same time that the
other HeapTuple fields are set, to make it more clear that all the code in
the loop operate on the "current" tuple in the chain, not the root tuple.
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,
test case and some additional changes to the fix by Heikki Linnakangas.
Backpatch to all supported versions (9.4).
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de
2019-08-07 11:40:49 +02:00
|
|
|
|
|
|
|
step r2: SELECT * FROM test WHERE i IN (5, 7)
|
2021-06-23 17:12:31 +02:00
|
|
|
i|t
|
|
|
|
-+----------------
|
|
|
|
5|apple
|
|
|
|
7|pear_hot_updated
|
|
|
|
(2 rows)
|
Fix predicate-locking of HOT updated rows.
In serializable mode, heap_hot_search_buffer() incorrectly acquired a
predicate lock on the root tuple, not the returned tuple that satisfied
the visibility checks. As explained in README-SSI, the predicate lock does
not need to be copied or extended to other tuple versions, but for that to
work, the correct, visible, tuple version must be locked in the first
place.
The original SSI commit had this bug in it, but it was fixed back in 2013,
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months
later in commit b89e151054. Wising up from that, add a regression test
to cover this, so that it doesn't get reintroduced again. Also, move the
code that sets 't_self', so that it happens at the same time that the
other HeapTuple fields are set, to make it more clear that all the code in
the loop operate on the "current" tuple in the chain, not the root tuple.
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,
test case and some additional changes to the fix by Heikki Linnakangas.
Backpatch to all supported versions (9.4).
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de
2019-08-07 11:40:49 +02:00
|
|
|
|
|
|
|
step w1: UPDATE test SET t = 'pear_xact1' WHERE i = 7
|
|
|
|
step w2: UPDATE test SET t = 'apple_xact2' WHERE i = 5
|
|
|
|
step c1: COMMIT;
|
|
|
|
step c2: COMMIT;
|
|
|
|
ERROR: could not serialize access due to read/write dependencies among transactions
|