From d065f5e91c8e2c23debf09252e5f7eb94f99dff4 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Tue, 20 Jun 2017 18:15:25 -0400 Subject: [PATCH] if we already hold lock, skip this tuple --- src/backend/access/heap/heapam.c | 41 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index 898950d9a0..ae0b214519 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -4906,8 +4906,10 @@ l5: * with the given xid, does the current transaction need to wait, fail, or can * it continue if it wanted to acquire a lock of the given mode? "needwait" * is set to true if waiting is necessary; if it can continue, then - * HeapTupleMayBeUpdated is returned. In case of a conflict, a different - * HeapTupleSatisfiesUpdate return code is returned. + * HeapTupleMayBeUpdated is returned. If the lock is already held by the + * current transaction, return HeapTupleSelfUpdated. In case of a conflict + * with another transaction, a different HeapTupleSatisfiesUpdate return code + * is returned. * * The held status is said to be hypothetical because it might correspond to a * lock held by a single Xid, i.e. not a real MultiXactId; we express it this @@ -4930,8 +4932,9 @@ test_lockmode_for_conflict(MultiXactStatus status, TransactionId xid, if (TransactionIdIsCurrentTransactionId(xid)) { /* - * Updated by our own transaction? Just return failure. This shouldn't - * normally happen. + * The tuple has already been locked by our own transaction. This is + * very rare but can happen if multiple transactions are trying to + * lock an ancient version of the same tuple. */ return HeapTupleSelfUpdated; } @@ -5100,6 +5103,22 @@ l4: members[i].xid, mode, &needwait); + /* + * If the tuple was already locked by ourselves in a + * previous iteration of this (say heap_lock_tuple was + * forced to restart the locking loop because of a change + * in xmax), then we hold the lock already on this tuple + * version and we don't need to do anything; and this is + * not an error condition either. We just need to skip + * this tuple and continue locking the next version in the + * update chain. + */ + if (res == HeapTupleSelfUpdated) + { + pfree(members); + goto next; + } + if (needwait) { LockBuffer(buf, BUFFER_LOCK_UNLOCK); @@ -5160,6 +5179,19 @@ l4: res = test_lockmode_for_conflict(status, rawxmax, mode, &needwait); + + /* + * If the tuple was already locked by ourselves in a previous + * iteration of this (say heap_lock_tuple was forced to + * restart the locking loop because of a change in xmax), then + * we hold the lock already on this tuple version and we don't + * need to do anything; and this is not an error condition + * either. We just need to skip this tuple and continue + * locking the next version in the update chain. + */ + if (res == HeapTupleSelfUpdated) + goto next; + if (needwait) { LockBuffer(buf, BUFFER_LOCK_UNLOCK); @@ -5221,6 +5253,7 @@ l4: END_CRIT_SECTION(); +next: /* if we find the end of update chain, we're done. */ if (mytup.t_data->t_infomask & HEAP_XMAX_INVALID || ItemPointerEquals(&mytup.t_self, &mytup.t_data->t_ctid) || -- 2.11.0