]> granicus.if.org Git - postgresql/commit
Avoid getting more than AccessShareLock when deparsing a query.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Mar 2014 00:31:12 +0000 (19:31 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Mar 2014 00:31:12 +0000 (19:31 -0500)
commit5ec41e345accd6d08142337aff071e9661fa55c8
treedf6563f83cfc4e3657870d4033e08136729bf7ba
parente7ec05562ed754fb60f75ea83efe103266a92015
Avoid getting more than AccessShareLock when deparsing a query.

In make_ruledef and get_query_def, we have long used AcquireRewriteLocks
to ensure that the querytree we are about to deparse is up-to-date and
the schemas of the underlying relations aren't changing.  Howwever, that
function thinks the query is about to be executed, so it acquires locks
that are stronger than necessary for the purpose of deparsing.  Thus for
example, if pg_dump asks to deparse a rule that includes "INSERT INTO t",
we'd acquire RowExclusiveLock on t.  That results in interference with
concurrent transactions that might for example ask for ShareLock on t.
Since pg_dump is documented as being purely read-only, this is unexpected.
(Worse, it used to actually be read-only; this behavior dates back only
to 8.1, cf commit ba4200246.)

Fix this by adding a parameter to AcquireRewriteLocks to tell it whether
we want the "real" execution locks or only AccessShareLock.

Report, diagnosis, and patch by Dean Rasheed.  Back-patch to all supported
branches.
src/backend/rewrite/rewriteHandler.c
src/backend/utils/adt/ruleutils.c
src/include/rewrite/rewriteHandler.h