aboutsummaryrefslogtreecommitdiff
path: root/src/backend/storage/lmgr/proc.c
diff options
context:
space:
mode:
authorAmit Kapila <akapila@postgresql.org>2023-07-06 08:41:30 +0530
committerAmit Kapila <akapila@postgresql.org>2023-07-06 08:41:30 +0530
commit3c1adbbf86c2cfa44ebed64bd01ed589ad0b832b (patch)
tree2b141de0dbdc1a9f9ae5827a6018648f4c624c43 /src/backend/storage/lmgr/proc.c
parentdc0b5841746c025f6e51b0a6ba0e423b2ac518f0 (diff)
downloadpostgresql-3c1adbbf86c2cfa44ebed64bd01ed589ad0b832b.tar.gz
postgresql-3c1adbbf86c2cfa44ebed64bd01ed589ad0b832b.zip
Revert the commits related to allowing page lock to conflict among parallel group members.
This commit reverts the work done by commits 3ba59ccc89 and 72e78d831a. 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
Diffstat (limited to 'src/backend/storage/lmgr/proc.c')
-rw-r--r--src/backend/storage/lmgr/proc.c12
1 files changed, 6 insertions, 6 deletions
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/storage/lmgr/proc.c
index dac921219fa..5b663a2997c 100644
--- a/src/backend/storage/lmgr/proc.c
+++ b/src/backend/storage/lmgr/proc.c
@@ -1021,12 +1021,12 @@ 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. This is not required for relation
- * extension or page locks 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.
+ * 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)
{