database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-09 06:21:09 +03:00
Code Activity

Allow page lock to conflict among parallel group members.

Browse Source 
This is required as it is no safer for two related processes to perform
clean up in gin indexes at a time than for unrelated processes to do the
same.  After acquiring page locks, we can acquire relation extension lock
but reverse never happens which means these will also not participate in
deadlock.  So, avoid checking wait edges from this lock.

Currently, the parallel mode is strictly read-only, but after this patch
we have the infrastructure to allow parallel inserts and parallel copy.

Author: Dilip Kumar, Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com
This commit is contained in:
Amit Kapila
2020-03-21 08:48:06 +05:30
parent a6d7e9fb28
commit 3ba59ccc89
5 changed files with 53 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/storage/lmgr/deadlock.c
View File

@@ -556,11 +556,12 @@ FindLockCycleRecurseMember(PGPROC *checkProc,
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.
* The relation extension or page lock can never participate in actual
* deadlock cycle. See Asserts in LockAcquireExtended. So, there is no
* advantage in checking wait edges from them.
*/
if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND)
if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND ||
(LOCK_LOCKTAG(*lock) == LOCKTAG_PAGE))
return false;
lockMethodTable = GetLocksMethodTable(lock);