pgsql: Fix ExecOpenScanRelation to take a lock on a ROW_MARK_COPY relat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix ExecOpenScanRelation to take a lock on a ROW_MARK_COPY relat
Date: 2015-03-24 19:53:16
Message-ID: E1YaUt2-0004hc-Cu@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

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.)

Branch
------
REL9_4_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/3171edddc4b8386e0f0ee2a68bb4b253d79444fc

Modified Files
--------------
src/backend/executor/execMain.c | 4 ++++
src/backend/executor/execUtils.c | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2015-03-24 23:52:53 pgsql: Add support for ALTER TABLE IF EXISTS ... RENAME CONSTRAINT
Previous Message Robert Haas 2015-03-24 00:41:47 Re: pgsql: Try to fix MSVC build of pg_rewind.