]> granicus.if.org Git - postgresql/commit
Change rewriter/planner/executor/plancache to depend on RTE rellockmode.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 2 Oct 2018 18:43:01 +0000 (14:43 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 2 Oct 2018 18:43:09 +0000 (14:43 -0400)
commit6e35939febf83069430fedda6f89ab1fbe0f9e10
tree7fcafdbda90ec0a6e3e788ab5a5f7252c7ebee47
parentcc2905e963e950d01cd2cb6c860638ce9506c63d
Change rewriter/planner/executor/plancache to depend on RTE rellockmode.

Instead of recomputing the required lock levels in all these places,
just use what commit fdba460a2 made the parser store in the RTE fields.
This already simplifies the code measurably in these places, and
follow-on changes will remove a bunch of no-longer-needed infrastructure.

In a few cases, this change causes us to acquire a higher lock level
than we did before.  This is OK primarily because said higher lock level
should've been acquired already at query parse time; thus, we're saving
a useless extra trip through the shared lock manager to acquire a lesser
lock alongside the original lock.  The only known exception to this is
that re-execution of a previously planned SELECT FOR UPDATE/SHARE query,
for a table that uses ROW_MARK_REFERENCE or ROW_MARK_COPY methods, might
have gotten only AccessShareLock before.  Now it will get RowShareLock
like the first execution did, which seems fine.

While there's more to do, push it in this state anyway, to let the
buildfarm help verify that nothing bad happened.

Amit Langote, reviewed by David Rowley and Jesper Pedersen,
and whacked around a bit more by me

Discussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp
src/backend/executor/execMain.c
src/backend/executor/execUtils.c
src/backend/optimizer/prep/prepunion.c
src/backend/rewrite/rewriteHandler.c
src/backend/utils/cache/plancache.c