aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/execProcnode.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2013-04-20 16:59:21 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2013-04-20 17:00:23 -0400
commitac63dca607e8e22247defbc8fe03b6baa3628c42 (patch)
treecb8bde0770619e75773c8b277f4d35730a708d67 /src/backend/executor/execProcnode.c
parent61b962345dd87276452922a5dbc21836266b43e0 (diff)
downloadpostgresql-ac63dca607e8e22247defbc8fe03b6baa3628c42.tar.gz
postgresql-ac63dca607e8e22247defbc8fe03b6baa3628c42.zip
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.
Diffstat (limited to 'src/backend/executor/execProcnode.c')
0 files changed, 0 insertions, 0 deletions