From 3fbfd5dbeca7931b40d9ec919fb64c3f08893848 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 24 Mar 2015 15:53:06 -0400 Subject: 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/execUtils.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'src/backend/executor/execUtils.c') diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c index e4e70c41b63..65e4904875a 100644 --- a/src/backend/executor/execUtils.c +++ b/src/backend/executor/execUtils.c @@ -819,7 +819,9 @@ ExecOpenScanRelation(EState *estate, Index scanrelid) { ExecRowMark *erm = lfirst(l); - if (erm->rti == scanrelid) + /* Keep this check in sync with InitPlan! */ + if (erm->rti == scanrelid && + erm->relation != NULL) { lockmode = NoLock; break; -- cgit v1.2.3