Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc5b7961

Browse files
committed
Fix predicate-locking of HOT updated rows.
In serializable mode, heap_hot_search_buffer() incorrectly acquired apredicate lock on the root tuple, not the returned tuple that satisfiedthe visibility checks. As explained in README-SSI, the predicate lock doesnot need to be copied or extended to other tuple versions, but for that towork, the correct, visible, tuple version must be locked in the firstplace.The original SSI commit had this bug in it, but it was fixed back in 2013,in commit81fbbfe. But unfortunately, it was reintroduced a few monthslater in commitb89e151. Wising up from that, add a regression testto cover this, so that it doesn't get reintroduced again. Also, move thecode that sets 't_self', so that it happens at the same time that theother HeapTuple fields are set, to make it more clear that all the code inthe 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
1 parentd16d241 commitc5b7961

File tree

4 files changed

+70
-17
lines changed

4 files changed

+70
-17
lines changed

‎src/backend/access/heap/heapam.c

Lines changed: 12 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -2041,6 +2041,7 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
20412041
{
20422042
Pagedp= (Page)BufferGetPage(buffer);
20432043
TransactionIdprev_xmax=InvalidTransactionId;
2044+
BlockNumberblkno;
20442045
OffsetNumberoffnum;
20452046
boolat_chain_start;
20462047
boolvalid;
@@ -2050,14 +2051,13 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
20502051
if (all_dead)
20512052
*all_dead=first_call;
20522053

2053-
Assert(TransactionIdIsValid(RecentGlobalXmin));
2054-
2055-
Assert(ItemPointerGetBlockNumber(tid)==BufferGetBlockNumber(buffer));
2054+
blkno=ItemPointerGetBlockNumber(tid);
20562055
offnum=ItemPointerGetOffsetNumber(tid);
20572056
at_chain_start=first_call;
20582057
skip= !first_call;
20592058

2060-
heapTuple->t_self=*tid;
2059+
Assert(TransactionIdIsValid(RecentGlobalXmin));
2060+
Assert(BufferGetBlockNumber(buffer)==blkno);
20612061

20622062
/* Scan through possible multiple members of HOT-chain */
20632063
for (;;)
@@ -2085,10 +2085,16 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
20852085
break;
20862086
}
20872087

2088+
/*
2089+
* Update heapTuple to point to the element of the HOT chain we're
2090+
* currently investigating. Having t_self set correctly is important
2091+
* because the SSI checks and the *Satisfies routine for historical
2092+
* MVCC snapshots need the correct tid to decide about the visibility.
2093+
*/
20882094
heapTuple->t_data= (HeapTupleHeader)PageGetItem(dp,lp);
20892095
heapTuple->t_len=ItemIdGetLength(lp);
20902096
heapTuple->t_tableOid=RelationGetRelid(relation);
2091-
ItemPointerSetOffsetNumber(&heapTuple->t_self,offnum);
2097+
ItemPointerSet(&heapTuple->t_self,blkno,offnum);
20922098

20932099
/*
20942100
* Shouldn't see a HEAP_ONLY tuple at chain start.
@@ -2114,21 +2120,10 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
21142120
*/
21152121
if (!skip)
21162122
{
2117-
/*
2118-
* For the benefit of logical decoding, have t_self point at the
2119-
* element of the HOT chain we're currently investigating instead
2120-
* of the root tuple of the HOT chain. This is important because
2121-
* the *Satisfies routine for historical mvcc snapshots needs the
2122-
* correct tid to decide about the visibility in some cases.
2123-
*/
2124-
ItemPointerSet(&(heapTuple->t_self),BufferGetBlockNumber(buffer),offnum);
2125-
21262123
/* If it's visible per the snapshot, we must return it */
21272124
valid=HeapTupleSatisfiesVisibility(heapTuple,snapshot,buffer);
21282125
CheckForSerializableConflictOut(valid,relation,heapTuple,
21292126
buffer,snapshot);
2130-
/* reset to original, non-redirected, tid */
2131-
heapTuple->t_self=*tid;
21322127

21332128
if (valid)
21342129
{
@@ -2160,7 +2155,7 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
21602155
if (HeapTupleIsHotUpdated(heapTuple))
21612156
{
21622157
Assert(ItemPointerGetBlockNumber(&heapTuple->t_data->t_ctid)==
2163-
ItemPointerGetBlockNumber(tid));
2158+
blkno);
21642159
offnum=ItemPointerGetOffsetNumber(&heapTuple->t_data->t_ctid);
21652160
at_chain_start= false;
21662161
prev_xmax=HeapTupleHeaderGetUpdateXid(heapTuple->t_data);
Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
Parsed test spec with 2 sessions
2+
3+
starting permutation: b1 b2 r1 r2 w1 w2 c1 c2
4+
step b1: BEGIN ISOLATION LEVEL SERIALIZABLE;
5+
step b2: BEGIN ISOLATION LEVEL SERIALIZABLE;
6+
step r1: SELECT * FROM test WHERE i IN (5, 7)
7+
i t
8+
9+
5 apple
10+
7 pear_hot_updated
11+
step r2: SELECT * FROM test WHERE i IN (5, 7)
12+
i t
13+
14+
5 apple
15+
7 pear_hot_updated
16+
step w1: UPDATE test SET t = 'pear_xact1' WHERE i = 7
17+
step w2: UPDATE test SET t = 'apple_xact2' WHERE i = 5
18+
step c1: COMMIT;
19+
step c2: COMMIT;
20+
ERROR: could not serialize access due to read/write dependencies among transactions

‎src/test/isolation/isolation_schedule

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@ test: partial-index
1717
test: two-ids
1818
test: multiple-row-versions
1919
test: index-only-scan
20+
test: predicate-lock-hot-tuple
2021
test: deadlock-simple
2122
test: deadlock-hard
2223
test: deadlock-soft
Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# Test predicate locks on HOT updated tuples.
2+
#
3+
# This test has two serializable transactions. Both select two rows
4+
# from the table, and then update one of them.
5+
# If these were serialized (run one at a time), the transaction that
6+
# runs later would see one of the rows to be updated.
7+
#
8+
# Any overlap between the transactions must cause a serialization failure.
9+
# We used to have a bug in predicate locking HOT updated tuples, which
10+
# caused the conflict to be missed, if the row was HOT updated.
11+
12+
setup
13+
{
14+
CREATETABLEtest (iintPRIMARYKEY,ttext);
15+
INSERTINTOtestVALUES (5,'apple'), (7,'pear'), (11,'banana');
16+
--HOT-update'pear'row.
17+
UPDATEtestSETt='pear_hot_updated'WHEREi=7;
18+
}
19+
20+
teardown
21+
{
22+
DROPTABLEtest;
23+
}
24+
25+
session"s1"
26+
step"b1" {BEGINISOLATIONLEVELSERIALIZABLE; }
27+
step"r1" {SELECT*FROMtestWHEREiIN (5,7) }
28+
step"w1" {UPDATEtestSETt='pear_xact1'WHEREi=7 }
29+
step"c1" {COMMIT; }
30+
31+
session"s2"
32+
step"b2" {BEGINISOLATIONLEVELSERIALIZABLE; }
33+
step"r2" {SELECT*FROMtestWHEREiIN (5,7) }
34+
step"w2" {UPDATEtestSETt='apple_xact2'WHEREi=5 }
35+
step"c2" {COMMIT; }
36+
37+
permutation"b1""b2""r1""r2""w1""w2""c1""c2"

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp