]> granicus.if.org Git - postgresql/commit
Fix ExecOpenScanRelation to take a lock on a ROW_MARK_COPY relation.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 24 Mar 2015 19:53:06 +0000 (15:53 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 24 Mar 2015 19:53:06 +0000 (15:53 -0400)
commit054723bcc5b03e40d6341b26b2dce5222a66ce4c
treea3dbf9364326f4d9a609e96f3a17a54ff4cd840d
parent9288645b596efde3a58e267896b38f8f089a2920
Fix ExecOpenScanRelation to take a lock on a ROW_MARK_COPY relation.

ExecOpenScanRelation assumed that any relation listed in the ExecRowMark
list has been locked by InitPlan; but this is not true if the rel's
markType is ROW_MARK_COPY, which is possible if it's a foreign table.

In most (possibly all) cases, failure to acquire a lock here isn't really
problematic because the parser, planner, or plancache would have taken the
appropriate lock already.  In principle though it might leave us vulnerable
to working with a relation that we hold no lock on, and in any case if the
executor isn't depending on previously-taken locks otherwise then it should
not do so for ROW_MARK_COPY relations.

Noted by Etsuro Fujita.  Back-patch to all active versions, since the
inconsistency has been there a long time.  (It's almost certainly
irrelevant in 9.0, since that predates foreign tables, but the code's
still wrong on its own terms.)
src/backend/executor/execMain.c
src/backend/executor/execUtils.c