]> granicus.if.org Git - postgresql/commit
Change executor to just Assert that table locks were already obtained.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 3 Oct 2018 20:05:05 +0000 (16:05 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 3 Oct 2018 20:05:12 +0000 (16:05 -0400)
commit9a3cebeaa7fdc1b0485475eb18121eb06968dc5d
tree7b327a9b86602ad9e1e256f17a285a423f380d5f
parentc03c1449c0925637d382bd16197796e6c5cab31d
Change executor to just Assert that table locks were already obtained.

Instead of locking tables during executor startup, just Assert that
suitable locks were obtained already during the parse/plan pipeline
(or re-obtained by the plan cache).  This must be so, else we have a
hazard that concurrent DDL has invalidated the plan.

This is pretty inefficient as well as undercommented, but it's all going
to go away shortly, so I didn't try hard.  This commit is just another
attempt to use the buildfarm to see if we've missed anything in the plan
to simplify the executor's table management.

Note that the change needed here in relation_open() exposes that
parallel workers now really are accessing tables without holding any
lock of their own, whereas they were not doing that before this commit.
This does not give me a warm fuzzy feeling about that aspect of parallel
query; it does not seem like a good design, and we now know that it's
had exactly no actual testing.  I think that we should modify parallel
query so that that change can be reverted.

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