]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Avoid getting more than AccessShareLock when deparsing a query.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Mar 2014 00:31:19 +0000 (19:31 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 7 Mar 2014 00:31:19 +0000 (19:31 -0500)
commitbed1259e52002ae2fb77a60b0f182dd93941ec60
tree6530a7d76a53c0f022893fd3978cf049402ae872
parent4521cc85075ca98b7337ae524c3e88ce723e61e9
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