]> 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:22 +0000 (19:31 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Mar 2014 00:31:22 +0000 (19:31 -0500)
commitf043bddfe0c1a3f31187849c2727d2eecdf06bcc
tree28099051dbd2fe9459608e7d0c5b01b55a63a065
parentb6e143458505708ac139520f067060f66b222e5b
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