summaryrefslogtreecommitdiff
path: root/src/backend/access/heap/heapam.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-10-06 15:49:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-10-06 15:49:37 -0400
commit29ef2b310da9892fda075ff9ee12da7f92d5da6e (patch)
tree9505320f23af01455ff4cde46bd33702b3ddf635 /src/backend/access/heap/heapam.c
parentf2343653f5b2aecfc759f36dbb3fd2a61f36853e (diff)
Restore sane locking behavior during parallel query.
Commit 9a3cebeaa changed things so that parallel workers didn't obtain any lock of their own on tables they access. That was clearly a bad idea, but I'd mistakenly supposed that it was the intended end result of the series of patches for simplifying the executor's lock management. Undo that change in relation_open(), and adjust ExecOpenScanRelation() so that it gets the correct lock if inside a parallel worker. In passing, clean up some more obsolete comments about when locks are acquired. Discussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp
Diffstat (limited to 'src/backend/access/heap/heapam.c')
-rw-r--r--src/backend/access/heap/heapam.c4
1 files changed, 0 insertions, 4 deletions
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 727d6776e13..5f1a69ca53c 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -1140,13 +1140,9 @@ relation_open(Oid relationId, LOCKMODE lockmode)
/*
* If we didn't get the lock ourselves, assert that caller holds one,
* except in bootstrap mode where no locks are used.
- *
- * Also, parallel workers currently assume that their parent holds locks
- * for tables used in the parallel query (a mighty shaky assumption).
*/
Assert(lockmode != NoLock ||
IsBootstrapProcessingMode() ||
- IsParallelWorker() ||
CheckRelationLockedByMe(r, AccessShareLock, true));
/* Make note that we've accessed a temporary relation */