aboutsummaryrefslogtreecommitdiff
path: root/contrib/jsonb_plpython/jsonb_plpython2u.control
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-10-03 16:05:05 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-10-03 16:05:12 -0400
commit9a3cebeaa7fdc1b0485475eb18121eb06968dc5d (patch)
tree7b327a9b86602ad9e1e256f17a285a423f380d5f /contrib/jsonb_plpython/jsonb_plpython2u.control
parentc03c1449c0925637d382bd16197796e6c5cab31d (diff)
downloadpostgresql-9a3cebeaa7fdc1b0485475eb18121eb06968dc5d.tar.gz
postgresql-9a3cebeaa7fdc1b0485475eb18121eb06968dc5d.zip
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
Diffstat (limited to 'contrib/jsonb_plpython/jsonb_plpython2u.control')
0 files changed, 0 insertions, 0 deletions