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

Commitf8d3018

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 parentd8652ec commitf8d3018

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
@@ -1529,6 +1529,7 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
15291529
{
15301530
Pagedp= (Page)BufferGetPage(buffer);
15311531
TransactionIdprev_xmax=InvalidTransactionId;
1532+
BlockNumberblkno;
15321533
OffsetNumberoffnum;
15331534
boolat_chain_start;
15341535
boolvalid;
@@ -1538,14 +1539,13 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
15381539
if (all_dead)
15391540
*all_dead=first_call;
15401541

1541-
Assert(TransactionIdIsValid(RecentGlobalXmin));
1542-
1543-
Assert(ItemPointerGetBlockNumber(tid)==BufferGetBlockNumber(buffer));
1542+
blkno=ItemPointerGetBlockNumber(tid);
15441543
offnum=ItemPointerGetOffsetNumber(tid);
15451544
at_chain_start=first_call;
15461545
skip= !first_call;
15471546

1548-
heapTuple->t_self=*tid;
1547+
Assert(TransactionIdIsValid(RecentGlobalXmin));
1548+
Assert(BufferGetBlockNumber(buffer)==blkno);
15491549

15501550
/* Scan through possible multiple members of HOT-chain */
15511551
for (;;)
@@ -1573,10 +1573,16 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
15731573
break;
15741574
}
15751575

1576+
/*
1577+
* Update heapTuple to point to the element of the HOT chain we're
1578+
* currently investigating. Having t_self set correctly is important
1579+
* because the SSI checks and the *Satisfies routine for historical
1580+
* MVCC snapshots need the correct tid to decide about the visibility.
1581+
*/
15761582
heapTuple->t_data= (HeapTupleHeader)PageGetItem(dp,lp);
15771583
heapTuple->t_len=ItemIdGetLength(lp);
15781584
heapTuple->t_tableOid=RelationGetRelid(relation);
1579-
ItemPointerSetOffsetNumber(&heapTuple->t_self,offnum);
1585+
ItemPointerSet(&heapTuple->t_self,blkno,offnum);
15801586

15811587
/*
15821588
* Shouldn't see a HEAP_ONLY tuple at chain start.
@@ -1602,21 +1608,10 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
16021608
*/
16031609
if (!skip)
16041610
{
1605-
/*
1606-
* For the benefit of logical decoding, have t_self point at the
1607-
* element of the HOT chain we're currently investigating instead
1608-
* of the root tuple of the HOT chain. This is important because
1609-
* the *Satisfies routine for historical mvcc snapshots needs the
1610-
* correct tid to decide about the visibility in some cases.
1611-
*/
1612-
ItemPointerSet(&(heapTuple->t_self),BufferGetBlockNumber(buffer),offnum);
1613-
16141611
/* If it's visible per the snapshot, we must return it */
16151612
valid=HeapTupleSatisfiesVisibility(heapTuple,snapshot,buffer);
16161613
CheckForSerializableConflictOut(valid,relation,heapTuple,
16171614
buffer,snapshot);
1618-
/* reset to original, non-redirected, tid */
1619-
heapTuple->t_self=*tid;
16201615

16211616
if (valid)
16221617
{
@@ -1648,7 +1643,7 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer,
16481643
if (HeapTupleIsHotUpdated(heapTuple))
16491644
{
16501645
Assert(ItemPointerGetBlockNumber(&heapTuple->t_data->t_ctid)==
1651-
ItemPointerGetBlockNumber(tid));
1646+
blkno);
16521647
offnum=ItemPointerGetOffsetNumber(&heapTuple->t_data->t_ctid);
16531648
at_chain_start= false;
16541649
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