Fix longstanding race condition in plancache.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 20 Apr 2013 20:59:41 +0000 (16:59 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 20 Apr 2013 20:59:41 +0000 (16:59 -0400)
commiteab46ee07fa317a8d374790def55726d9e414b88
tree6af3e10c25c7a2b60f6f47ffcbe6db29e4c734bb
parent2534ac426d2dc9270e2cccf2d64c11879bc71825
Fix longstanding race condition in plancache.c.

When creating or manipulating a cached plan for a transaction control
command (particularly ROLLBACK), we must not perform any catalog accesses,
since we might be in an aborted transaction.  However, plancache.c busily
saved or examined the search_path for every cached plan.  If we were
unlucky enough to do this at a moment where the path's expansion into
schema OIDs wasn't already cached, we'd do some catalog accesses; and with
some more bad luck such as an ill-timed signal arrival, that could lead to
crashes or Assert failures, as exhibited in bug #8095 from Nachiket Vaidya.
Fortunately, there's no real need to consider the search path for such
commands, so we can just skip the relevant steps when the subject statement
is a TransactionStmt.  This is somewhat related to bug #5269, though the
failure happens during initial cached-plan creation rather than
revalidation.

This bug has been there since the plan cache was invented, so back-patch
to all supported branches.
src/backend/utils/cache/plancache.c