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

Commit9d20b0e

Browse files
committed
Revert "Avoid spurious deadlocks when upgrading a tuple lock"
This reverts commits3da73d6 andde87a08.This code has some tricky corner cases that I'm not sure are correct andnot properly tested anyway, so I'm reverting the whole thing for nextweek's releases (reintroducing the deadlock bug that we set to fix).I'll try again afterwards.Discussion:https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org
1 parent16c4e76 commit9d20b0e

File tree

5 files changed

+21
-280
lines changed

5 files changed

+21
-280
lines changed

‎src/backend/access/heap/README.tuplock‎

Lines changed: 0 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -36,16 +36,6 @@ do LockTuple as well, if there is any conflict, to ensure that they don't
3636
starve out waiting exclusive-lockers. However, if there is not any active
3737
conflict for a tuple, we don't incur any extra overhead.
3838

39-
We make an exception to the above rule for those lockers that already hold
40-
some lock on a tuple and attempt to acquire a stronger one on it. In that
41-
case, we skip the LockTuple() call even when there are conflicts, provided
42-
that the target tuple is being locked, updated or deleted by multiple sessions
43-
concurrently. Failing to skip the lock would risk a deadlock, e.g., between a
44-
session that was first to record its weaker lock in the tuple header and would
45-
be waiting on the LockTuple() call to upgrade to the stronger lock level, and
46-
another session that has already done LockTuple() and is waiting for the first
47-
session transaction to release its tuple header-level lock.
48-
4939
We provide four levels of tuple locking strength: SELECT FOR UPDATE obtains an
5040
exclusive lock which prevents any kind of modification of the tuple. This is
5141
the lock level that is implicitly taken by DELETE operations, and also by

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

Lines changed: 21 additions & 62 deletions
Original file line numberDiff line numberDiff line change
@@ -95,7 +95,7 @@ static void GetMultiXactIdHintBits(MultiXactId multi, uint16 *new_infomask,
9595
staticTransactionIdMultiXactIdGetUpdateXid(TransactionIdxmax,
9696
uint16t_infomask);
9797
staticboolDoesMultiXactIdConflict(MultiXactIdmulti,uint16infomask,
98-
LockTupleModelockmode,bool*current_is_member);
98+
LockTupleModelockmode);
9999
staticvoidMultiXactIdWait(MultiXactIdmulti,MultiXactStatusstatus,uint16infomask,
100100
Relationrel,ItemPointerctid,XLTW_Operoper,
101101
int*remaining);
@@ -2547,20 +2547,15 @@ heap_delete(Relation relation, ItemPointer tid,
25472547
*/
25482548
if (infomask&HEAP_XMAX_IS_MULTI)
25492549
{
2550-
boolcurrent_is_member= false;
2551-
2550+
/* wait for multixact */
25522551
if (DoesMultiXactIdConflict((MultiXactId)xwait,infomask,
2553-
LockTupleExclusive,&current_is_member))
2552+
LockTupleExclusive))
25542553
{
25552554
LockBuffer(buffer,BUFFER_LOCK_UNLOCK);
25562555

2557-
/*
2558-
* Acquire the lock, if necessary (but skip it when we're
2559-
* requesting a lock and already have one; avoids deadlock).
2560-
*/
2561-
if (!current_is_member)
2562-
heap_acquire_tuplock(relation,&(tp.t_self),LockTupleExclusive,
2563-
LockWaitBlock,&have_tuple_lock);
2556+
/* acquire tuple lock, if necessary */
2557+
heap_acquire_tuplock(relation,&(tp.t_self),LockTupleExclusive,
2558+
LockWaitBlock,&have_tuple_lock);
25642559

25652560
/* wait for multixact */
25662561
MultiXactIdWait((MultiXactId)xwait,MultiXactStatusUpdate,infomask,
@@ -3131,20 +3126,15 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
31313126
{
31323127
TransactionIdupdate_xact;
31333128
intremain;
3134-
boolcurrent_is_member= false;
31353129

31363130
if (DoesMultiXactIdConflict((MultiXactId)xwait,infomask,
3137-
*lockmode,&current_is_member))
3131+
*lockmode))
31383132
{
31393133
LockBuffer(buffer,BUFFER_LOCK_UNLOCK);
31403134

3141-
/*
3142-
* Acquire the lock, if necessary (but skip it when we're
3143-
* requesting a lock and already have one; avoids deadlock).
3144-
*/
3145-
if (!current_is_member)
3146-
heap_acquire_tuplock(relation,&(oldtup.t_self),*lockmode,
3147-
LockWaitBlock,&have_tuple_lock);
3135+
/* acquire tuple lock, if necessary */
3136+
heap_acquire_tuplock(relation,&(oldtup.t_self),*lockmode,
3137+
LockWaitBlock,&have_tuple_lock);
31483138

31493139
/* wait for multixact */
31503140
MultiXactIdWait((MultiXactId)xwait,mxact_status,infomask,
@@ -4038,7 +4028,6 @@ heap_lock_tuple(Relation relation, HeapTuple tuple,
40384028
uint16infomask;
40394029
uint16infomask2;
40404030
boolrequire_sleep;
4041-
boolskip_tuple_lock= false;
40424031
ItemPointerDatat_ctid;
40434032

40444033
/* must copy state data before unlocking buffer */
@@ -4092,21 +4081,6 @@ heap_lock_tuple(Relation relation, HeapTuple tuple,
40924081
result=TM_Ok;
40934082
gotoout_unlocked;
40944083
}
4095-
else
4096-
{
4097-
/*
4098-
* Disable acquisition of the heavyweight tuple lock.
4099-
* Otherwise, when promoting a weaker lock, we might
4100-
* deadlock with another locker that has acquired the
4101-
* heavyweight tuple lock and is waiting for our
4102-
* transaction to finish.
4103-
*
4104-
* Note that in this case we still need to wait for
4105-
* the multixact if required, to avoid acquiring
4106-
* conflicting locks.
4107-
*/
4108-
skip_tuple_lock= true;
4109-
}
41104084
}
41114085

41124086
if (members)
@@ -4261,7 +4235,7 @@ heap_lock_tuple(Relation relation, HeapTuple tuple,
42614235
if (infomask&HEAP_XMAX_IS_MULTI)
42624236
{
42634237
if (!DoesMultiXactIdConflict((MultiXactId)xwait,infomask,
4264-
mode,NULL))
4238+
mode))
42654239
{
42664240
/*
42674241
* No conflict, but if the xmax changed under us in the
@@ -4338,15 +4312,13 @@ heap_lock_tuple(Relation relation, HeapTuple tuple,
43384312
/*
43394313
* Acquire tuple lock to establish our priority for the tuple, or
43404314
* die trying. LockTuple will release us when we are next-in-line
4341-
* for the tuple. We must do this even if we are share-locking,
4342-
* but not if we already have a weaker lock on the tuple.
4315+
* for the tuple. We must do this even if we are share-locking.
43434316
*
43444317
* If we are forced to "start over" below, we keep the tuple lock;
43454318
* this arranges that we stay at the head of the line while
43464319
* rechecking tuple state.
43474320
*/
4348-
if (!skip_tuple_lock&&
4349-
!heap_acquire_tuplock(relation,tid,mode,wait_policy,
4321+
if (!heap_acquire_tuplock(relation,tid,mode,wait_policy,
43504322
&have_tuple_lock))
43514323
{
43524324
/*
@@ -6544,13 +6516,10 @@ HeapTupleGetUpdateXid(HeapTupleHeader tuple)
65446516
* tuple lock of the given strength?
65456517
*
65466518
* The passed infomask pairs up with the given multixact in the tuple header.
6547-
*
6548-
* If current_is_member is not NULL, it is set to 'true' if the current
6549-
* transaction is a member of the given multixact.
65506519
*/
65516520
staticbool
65526521
DoesMultiXactIdConflict(MultiXactIdmulti,uint16infomask,
6553-
LockTupleModelockmode,bool*current_is_member)
6522+
LockTupleModelockmode)
65546523
{
65556524
intnmembers;
65566525
MultiXactMember*members;
@@ -6571,26 +6540,17 @@ DoesMultiXactIdConflict(MultiXactId multi, uint16 infomask,
65716540
TransactionIdmemxid;
65726541
LOCKMODEmemlockmode;
65736542

6574-
if (result&& (current_is_member==NULL||*current_is_member))
6575-
break;
6576-
65776543
memlockmode=LOCKMODE_from_mxstatus(members[i].status);
65786544

6579-
/* ignore members from current xact (but track their presence) */
6580-
memxid=members[i].xid;
6581-
if (TransactionIdIsCurrentTransactionId(memxid))
6582-
{
6583-
if (current_is_member!=NULL)
6584-
*current_is_member= true;
6585-
continue;
6586-
}
6587-
elseif (result)
6588-
continue;
6589-
65906545
/* ignore members that don't conflict with the lock we want */
65916546
if (!DoLockModesConflict(memlockmode,wanted))
65926547
continue;
65936548

6549+
/* ignore members from current xact */
6550+
memxid=members[i].xid;
6551+
if (TransactionIdIsCurrentTransactionId(memxid))
6552+
continue;
6553+
65946554
if (ISUPDATE_from_mxstatus(members[i].status))
65956555
{
65966556
/* ignore aborted updaters */
@@ -6607,11 +6567,10 @@ DoesMultiXactIdConflict(MultiXactId multi, uint16 infomask,
66076567
/*
66086568
* Whatever remains are either live lockers that conflict with our
66096569
* wanted lock, and updaters that are not aborted. Those conflict
6610-
* with what we want. Set up to return true, but keep going to
6611-
* look for the current transaction among the multixact members,
6612-
* if needed.
6570+
* with what we want, so return true.
66136571
*/
66146572
result= true;
6573+
break;
66156574
}
66166575
pfree(members);
66176576
}

‎src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out‎

Lines changed: 0 additions & 150 deletions
This file was deleted.

‎src/test/isolation/isolation_schedule‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,6 @@ test: reindex-concurrently
4949
test: propagate-lock-delete
5050
test: tuplelock-conflict
5151
test: tuplelock-update
52-
test: tuplelock-upgrade-no-deadlock
5352
test: freeze-the-dead
5453
test: nowait
5554
test: nowait-2

0 commit comments

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