diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2013-04-20 16:59:27 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2013-04-20 16:59:27 -0400 |
commit | c37ec840cfe80e8fde05bc87417ced2765ab17dd (patch) | |
tree | cc897eef2a2829634624f4abdc42208d69b51226 /src/backend/access/gist/gistscan.c | |
parent | e3a7675e671803345f20c826a5807f57f599e0a1 (diff) | |
download | postgresql-c37ec840cfe80e8fde05bc87417ced2765ab17dd.tar.gz postgresql-c37ec840cfe80e8fde05bc87417ced2765ab17dd.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/access/gist/gistscan.c')
0 files changed, 0 insertions, 0 deletions