aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeTidscan.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/executor/nodeTidscan.c
parentf2343653f5b2aecfc759f36dbb3fd2a61f36853e (diff)
downloadpostgresql-29ef2b310da9892fda075ff9ee12da7f92d5da6e.tar.gz
postgresql-29ef2b310da9892fda075ff9ee12da7f92d5da6e.zip
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/executor/nodeTidscan.c')
-rw-r--r--src/backend/executor/nodeTidscan.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/executor/nodeTidscan.c b/src/backend/executor/nodeTidscan.c
index 593185f726b..d21d6553e42 100644
--- a/src/backend/executor/nodeTidscan.c
+++ b/src/backend/executor/nodeTidscan.c
@@ -531,7 +531,7 @@ ExecInitTidScan(TidScan *node, EState *estate, int eflags)
tidstate->tss_TidPtr = -1;
/*
- * open the base relation and acquire appropriate lock on it.
+ * open the scan relation
*/
currentRelation = ExecOpenScanRelation(estate, node->scan.scanrelid, eflags);