]> granicus.if.org Git - postgresql/commit
Restore sane locking behavior during parallel query.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 6 Oct 2018 19:49:37 +0000 (15:49 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 6 Oct 2018 19:49:37 +0000 (15:49 -0400)
commit29ef2b310da9892fda075ff9ee12da7f92d5da6e
tree9505320f23af01455ff4cde46bd33702b3ddf635
parentf2343653f5b2aecfc759f36dbb3fd2a61f36853e
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
src/backend/access/heap/heapam.c
src/backend/executor/execMain.c
src/backend/executor/execUtils.c
src/backend/executor/nodeBitmapHeapscan.c
src/backend/executor/nodeCustom.c
src/backend/executor/nodeForeignscan.c
src/backend/executor/nodeIndexonlyscan.c
src/backend/executor/nodeIndexscan.c
src/backend/executor/nodeSamplescan.c
src/backend/executor/nodeSeqscan.c
src/backend/executor/nodeTidscan.c