From 2163a6c79e233f285674a8832f420078922a444d Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Sat, 14 Mar 2020 17:48:17 +0530 Subject: [PATCH v10 3/4] Allow relation extension lock to conflict among parallel group members. This is required as it is no safer for two related processes to extend the same relation at a time than for unrelated processes to do the same. We don't acquire a heavyweight lock on any other object after relation extension lock which means such a lock can never participate in the deadlock cycle. So, avoid checking wait edges from this lock. This provides an infrastructure to allow parallel operations like insert, copy, etc. which were earlier not possible as parallel group members won't conflict for relation extension lock. Author: Dilip Kumar, Amit Kapila Reviewed-by: Amit Kapila and Kuntal Ghosh Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com --- src/backend/storage/lmgr/deadlock.c | 8 ++++++++ src/backend/storage/lmgr/lock.c | 10 ++++++++++ src/backend/storage/lmgr/proc.c | 8 +++++++- src/include/storage/lock.h | 1 + 4 files changed, 26 insertions(+), 1 deletion(-) diff --git a/src/backend/storage/lmgr/deadlock.c b/src/backend/storage/lmgr/deadlock.c index f8c5df0..59060b6 100644 --- a/src/backend/storage/lmgr/deadlock.c +++ b/src/backend/storage/lmgr/deadlock.c @@ -555,6 +555,14 @@ FindLockCycleRecurseMember(PGPROC *checkProc, int numLockModes, lm; + /* + * The relation extension lock can never participate in actual deadlock + * cycle. See Assert in LockAcquireExtended. So, there is no advantage + * in checking wait edges from it. + */ + if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND) + return false; + lockMethodTable = GetLocksMethodTable(lock); numLockModes = lockMethodTable->numLockModes; conflictMask = lockMethodTable->conflictTab[checkProc->waitLockMode]; diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c index 6a4bda57..658bcf1 100644 --- a/src/backend/storage/lmgr/lock.c +++ b/src/backend/storage/lmgr/lock.c @@ -1475,6 +1475,16 @@ LockCheckConflicts(LockMethod lockMethodTable, } /* + * The relation extension lock conflict even between the group members. + */ + if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND) + { + PROCLOCK_PRINT("LockCheckConflicts: conflicting (group)", + proclock); + return true; + } + + /* * Locks held in conflicting modes by members of our own lock group are * not real conflicts; we can subtract those out and see if we still have * a conflict. This is O(N) in the number of processes holding or diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c index eb321f7..fa07ddf 100644 --- a/src/backend/storage/lmgr/proc.c +++ b/src/backend/storage/lmgr/proc.c @@ -1077,7 +1077,13 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable) /* * If group locking is in use, locks held by members of my locking group - * need to be included in myHeldLocks. + * need to be included in myHeldLocks. This is not required for relation + * extension lock which conflict among group members. However, including + * them in myHeldLocks will give group members the priority to get those + * locks as compared to other backends which are also trying to acquire + * those locks. OTOH, we can avoid giving priority to group members for + * that kind of locks, but there doesn't appear to be a clear advantage of + * the same. */ if (leader != NULL) { diff --git a/src/include/storage/lock.h b/src/include/storage/lock.h index fc0a712..a89e54d 100644 --- a/src/include/storage/lock.h +++ b/src/include/storage/lock.h @@ -301,6 +301,7 @@ typedef struct LOCK } LOCK; #define LOCK_LOCKMETHOD(lock) ((LOCKMETHODID) (lock).tag.locktag_lockmethodid) +#define LOCK_LOCKTAG(lock) ((LockTagType) (lock).tag.locktag_type) /* -- 1.8.3.1