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

Commit85f6b49

Browse files
author
Amit Kapila
committed
Allow relation extension lock to conflict among parallel group members.
This is required as it is no safer for two related processes to extend thesame relation at a time than for unrelated processes to do the same. Wedon't acquire a heavyweight lock on any other object after relationextension lock which means such a lock can never participate in thedeadlock 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'tconflict for relation extension lock.Author: Dilip Kumar, Amit KapilaReviewed-by: Amit Kapila, Kuntal Ghosh and Sawada MasahikoDiscussion:https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com
1 parentb27e1b3 commit85f6b49

File tree

4 files changed

+26
-1
lines changed

4 files changed

+26
-1
lines changed

‎src/backend/storage/lmgr/deadlock.c

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -555,6 +555,14 @@ FindLockCycleRecurseMember(PGPROC *checkProc,
555555
intnumLockModes,
556556
lm;
557557

558+
/*
559+
* The relation extension lock can never participate in actual deadlock
560+
* cycle. See Assert in LockAcquireExtended. So, there is no advantage
561+
* in checking wait edges from it.
562+
*/
563+
if (LOCK_LOCKTAG(*lock)==LOCKTAG_RELATION_EXTEND)
564+
return false;
565+
558566
lockMethodTable=GetLocksMethodTable(lock);
559567
numLockModes=lockMethodTable->numLockModes;
560568
conflictMask=lockMethodTable->conflictTab[checkProc->waitLockMode];

‎src/backend/storage/lmgr/lock.c

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1469,6 +1469,16 @@ LockCheckConflicts(LockMethod lockMethodTable,
14691469
return true;
14701470
}
14711471

1472+
/*
1473+
* The relation extension lock conflict even between the group members.
1474+
*/
1475+
if (LOCK_LOCKTAG(*lock)==LOCKTAG_RELATION_EXTEND)
1476+
{
1477+
PROCLOCK_PRINT("LockCheckConflicts: conflicting (group)",
1478+
proclock);
1479+
return true;
1480+
}
1481+
14721482
/*
14731483
* Locks held in conflicting modes by members of our own lock group are
14741484
* not real conflicts; we can subtract those out and see if we still have

‎src/backend/storage/lmgr/proc.c

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1077,7 +1077,13 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
10771077

10781078
/*
10791079
* If group locking is in use, locks held by members of my locking group
1080-
* need to be included in myHeldLocks.
1080+
* need to be included in myHeldLocks. This is not required for relation
1081+
* extension lock which conflict among group members. However, including
1082+
* them in myHeldLocks will give group members the priority to get those
1083+
* locks as compared to other backends which are also trying to acquire
1084+
* those locks. OTOH, we can avoid giving priority to group members for
1085+
* that kind of locks, but there doesn't appear to be a clear advantage of
1086+
* the same.
10811087
*/
10821088
if (leader!=NULL)
10831089
{

‎src/include/storage/lock.h

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -301,6 +301,7 @@ typedef struct LOCK
301301
}LOCK;
302302

303303
#defineLOCK_LOCKMETHOD(lock) ((LOCKMETHODID) (lock).tag.locktag_lockmethodid)
304+
#defineLOCK_LOCKTAG(lock) ((LockTagType) (lock).tag.locktag_type)
304305

305306

306307
/*

0 commit comments

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