database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-07 00:36:50 +03:00
Code Activity

Restore sane locking behavior during parallel query.

Browse Source 
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
This commit is contained in:
Tom Lane
2018-10-06 15:49:37 -04:00
parent f2343653f5
commit 29ef2b310d
11 changed files with 34 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/backend/executor/nodeBitmapHeapscan.c
View File

@ -899,16 +899,12 @@ ExecInitBitmapHeapScan(BitmapHeapScan *node, EState *estate, int eflags)
ExecAssignExprContext(estate, &scanstate->ss.ps);
/*
* open the base relation and acquire appropriate lock on it.
* open the scan relation
*/
currentRelation = ExecOpenScanRelation(estate, node->scan.scanrelid, eflags);
/*
* initialize child nodes
*
* We do this after ExecOpenScanRelation because the child nodes will open
* indexscans on our relation's indexes, and we want to be sure we have
* acquired a lock on the relation first.
*/
outerPlanState(scanstate) = ExecInitNode(outerPlan(node), estate, eflags);