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
Appearance settings

Commit cc32ec2

Browse filesBrowse files
author
Amit Kapila
committed
Revert the commits related to allowing page lock to conflict among parallel group members.
This commit reverts the work done by commits 3ba59cc and 72e78d8. Those commits were incorrect in asserting that we never acquire any other heavy-weight lock after acquring page lock other than relation extension lock. We can acquire a lock on catalogs while doing catalog look up after acquring page lock. This won't impact any existing feature but we need to think some other way to achieve this before parallelizing other write operations or even improving the parallelism in vacuum (like allowing multiple workers for an index). Reported-by: Jaime Casanova Author: Amit Kapila Backpatch-through: 13 Discussion: https://postgr.es/m/CAJKUy5jffnRKNvRHKQ0LynRb0RJC-o4P8Ku3x9vGAVLwDBWumQ@mail.gmail.com
1 parent ae6d06f commit cc32ec2
Copy full SHA for cc32ec2

File tree

5 files changed

+34
-65
lines changed
Filter options

5 files changed

+34
-65
lines changed

‎src/backend/optimizer/plan/planner.c

Copy file name to clipboardExpand all lines: src/backend/optimizer/plan/planner.c
+7-5Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -330,11 +330,13 @@ standard_planner(Query *parse, const char *query_string, int cursorOptions,
330330
* functions are present in the query tree.
331331
*
332332
* (Note that we do allow CREATE TABLE AS, SELECT INTO, and CREATE
333-
* MATERIALIZED VIEW to use parallel plans, but as of now, only the leader
334-
* backend writes into a completely new table. In the future, we can
335-
* extend it to allow workers to write into the table. However, to allow
336-
* parallel updates and deletes, we have to solve other problems,
337-
* especially around combo CIDs.)
333+
* MATERIALIZED VIEW to use parallel plans, but this is safe only because
334+
* the command is writing into a completely new table which workers won't
335+
* be able to see. If the workers could see the table, the fact that
336+
* group locking would cause them to ignore the leader's heavyweight
337+
* GIN page locks would make this unsafe. We'll have to fix that somehow
338+
* if we want to allow parallel inserts in general; updates and deletes
339+
* have additional problems especially around combo CIDs.)
338340
*
339341
* For now, we don't try to use parallel mode if we're running inside a
340342
* parallel worker. We might eventually be able to relax this

‎src/backend/storage/lmgr/README

Copy file name to clipboardExpand all lines: src/backend/storage/lmgr/README
+13-21Lines changed: 13 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -597,10 +597,10 @@ deadlock detection algorithm very much, but it makes the bookkeeping more
597597
complicated.
598598

599599
We choose to regard locks held by processes in the same parallel group as
600-
non-conflicting with the exception of relation extension and page locks. This
601-
means that two processes in a parallel group can hold a self-exclusive lock on
602-
the same relation at the same time, or one process can acquire an AccessShareLock
603-
while the other already holds AccessExclusiveLock. This might seem dangerous and
600+
non-conflicting with the exception of relation extension lock. This means that
601+
two processes in a parallel group can hold a self-exclusive lock on the same
602+
relation at the same time, or one process can acquire an AccessShareLock while
603+
the other already holds AccessExclusiveLock. This might seem dangerous and
604604
could be in some cases (more on that below), but if we didn't do this then
605605
parallel query would be extremely prone to self-deadlock. For example, a
606606
parallel query against a relation on which the leader already had
@@ -638,23 +638,15 @@ the other is safe enough. Problems would occur if the leader initiated
638638
parallelism from a point in the code at which it had some backend-private
639639
state that made table access from another process unsafe, for example after
640640
calling SetReindexProcessing and before calling ResetReindexProcessing,
641-
catastrophe could ensue, because the worker won't have that state.
642-
643-
To allow parallel inserts and parallel copy, we have ensured that relation
644-
extension and page locks don't participate in group locking which means such
645-
locks can conflict among the same group members. This is required as it is no
646-
safer for two related processes to extend the same relation or perform clean up
647-
in gin indexes at a time than for unrelated processes to do the same. We don't
648-
acquire a heavyweight lock on any other object after relation extension lock
649-
which means such a lock can never participate in the deadlock cycle. After
650-
acquiring page locks, we can acquire relation extension lock but reverse never
651-
happens, so those will also not participate in deadlock. To allow for other
652-
parallel writes like parallel update or parallel delete, we'll either need to
653-
(1) further enhance the deadlock detector to handle those tuple locks in a
654-
different way than other types; or (2) have parallel workers use some other
655-
mutual exclusion method for such cases. Currently, the parallel mode is
656-
strictly read-only, but now we have the infrastructure to allow parallel
657-
inserts and parallel copy.
641+
catastrophe could ensue, because the worker won't have that state. Similarly,
642+
problems could occur with certain kinds of non-relation locks, such as
643+
GIN page locks. It's no safer for two related processes to perform GIN clean
644+
up at the same time than for unrelated processes to do the same.
645+
However, since parallel mode is strictly read-only at present, neither this
646+
nor most of the similar cases can arise at present. To allow parallel writes,
647+
we'll either need to (1) further enhance the deadlock detector to handle those
648+
types of locks in a different way than other types; or (2) have parallel
649+
workers use some other mutual exclusion method for such cases.
658650

659651
Group locking adds three new members to each PGPROC: lockGroupLeader,
660652
lockGroupMembers, and lockGroupLink. A PGPROC's lockGroupLeader is NULL for

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

Copy file name to clipboardExpand all lines: src/backend/storage/lmgr/deadlock.c
+4-5Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -546,12 +546,11 @@ FindLockCycleRecurseMember(PGPROC *checkProc,
546546
lm;
547547

548548
/*
549-
* The relation extension or page lock can never participate in actual
550-
* deadlock cycle. See Asserts in LockAcquireExtended. So, there is no
551-
* advantage in checking wait edges from them.
549+
* The relation extension lock can never participate in actual deadlock
550+
* cycle. See Assert in LockAcquireExtended. So, there is no advantage
551+
* in checking wait edges from it.
552552
*/
553-
if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND ||
554-
(LOCK_LOCKTAG(*lock) == LOCKTAG_PAGE))
553+
if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND)
555554
return false;
556555

557556
lockMethodTable = GetLocksMethodTable(lock);

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

Copy file name to clipboardExpand all lines: src/backend/storage/lmgr/lock.c
+4-28Lines changed: 4 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -186,18 +186,6 @@ static int FastPathLocalUseCount = 0;
186186
*/
187187
static bool IsRelationExtensionLockHeld PG_USED_FOR_ASSERTS_ONLY = false;
188188

189-
/*
190-
* Flag to indicate if the page lock is held by this backend. We don't
191-
* acquire any other heavyweight lock while holding the page lock except for
192-
* relation extension. However, these locks are never taken in reverse order
193-
* which implies that page locks will also never participate in the deadlock
194-
* cycle.
195-
*
196-
* Similar to relation extension, page locks are also held for a short
197-
* duration, so imposing such a restriction won't hurt.
198-
*/
199-
static bool IsPageLockHeld PG_USED_FOR_ASSERTS_ONLY = false;
200-
201189
/* Macros for manipulating proc->fpLockBits */
202190
#define FAST_PATH_BITS_PER_SLOT 3
203191
#define FAST_PATH_LOCKNUMBER_OFFSET 1
@@ -886,13 +874,6 @@ LockAcquireExtended(const LOCKTAG *locktag,
886874
*/
887875
Assert(!IsRelationExtensionLockHeld);
888876

889-
/*
890-
* We don't acquire any other heavyweight lock while holding the page lock
891-
* except for relation extension.
892-
*/
893-
Assert(!IsPageLockHeld ||
894-
(locktag->locktag_type == LOCKTAG_RELATION_EXTEND));
895-
896877
/*
897878
* Prepare to emit a WAL record if acquisition of this lock needs to be
898879
* replayed in a standby server.
@@ -1340,10 +1321,10 @@ SetupLockInTable(LockMethod lockMethodTable, PGPROC *proc,
13401321
}
13411322

13421323
/*
1343-
* Check and set/reset the flag that we hold the relation extension/page lock.
1324+
* Check and set/reset the flag that we hold the relation extension lock.
13441325
*
13451326
* It is callers responsibility that this function is called after
1346-
* acquiring/releasing the relation extension/page lock.
1327+
* acquiring/releasing the relation extension lock.
13471328
*
13481329
* Pass acquired as true if lock is acquired, false otherwise.
13491330
*/
@@ -1353,9 +1334,6 @@ CheckAndSetLockHeld(LOCALLOCK *locallock, bool acquired)
13531334
#ifdef USE_ASSERT_CHECKING
13541335
if (LOCALLOCK_LOCKTAG(*locallock) == LOCKTAG_RELATION_EXTEND)
13551336
IsRelationExtensionLockHeld = acquired;
1356-
else if (LOCALLOCK_LOCKTAG(*locallock) == LOCKTAG_PAGE)
1357-
IsPageLockHeld = acquired;
1358-
13591337
#endif
13601338
}
13611339

@@ -1480,11 +1458,9 @@ LockCheckConflicts(LockMethod lockMethodTable,
14801458
}
14811459

14821460
/*
1483-
* The relation extension or page lock conflict even between the group
1484-
* members.
1461+
* The relation extension lock conflict even between the group members.
14851462
*/
1486-
if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND ||
1487-
(LOCK_LOCKTAG(*lock) == LOCKTAG_PAGE))
1463+
if (LOCK_LOCKTAG(*lock) == LOCKTAG_RELATION_EXTEND)
14881464
{
14891465
PROCLOCK_PRINT("LockCheckConflicts: conflicting (group)",
14901466
proclock);

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

Copy file name to clipboardExpand all lines: src/backend/storage/lmgr/proc.c
+6-6Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1021,12 +1021,12 @@ ProcSleep(LOCALLOCK *locallock, LockMethod lockMethodTable)
10211021
/*
10221022
* If group locking is in use, locks held by members of my locking group
10231023
* need to be included in myHeldLocks. This is not required for relation
1024-
* extension or page locks which conflict among group members. However,
1025-
* including them in myHeldLocks will give group members the priority to
1026-
* get those locks as compared to other backends which are also trying to
1027-
* acquire those locks. OTOH, we can avoid giving priority to group
1028-
* members for that kind of locks, but there doesn't appear to be a clear
1029-
* advantage of the same.
1024+
* extension lock which conflict among group members. However, including
1025+
* them in myHeldLocks will give group members the priority to get those
1026+
* locks as compared to other backends which are also trying to acquire
1027+
* those locks. OTOH, we can avoid giving priority to group members for
1028+
* that kind of locks, but there doesn't appear to be a clear advantage of
1029+
* the same.
10301030
*/
10311031
if (leader != NULL)
10321032
{

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.