From 054723bcc5b03e40d6341b26b2dce5222a66ce4c 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/execMain.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'src/backend/executor/execMain.c') diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index d46cdf8c349..614b00bd24f 100644 --- a/src/backend/executor/execMain.c +++ b/src/backend/executor/execMain.c @@ -820,6 +820,10 @@ InitPlan(QueryDesc *queryDesc, int eflags) if (rc->isParent) continue; + /* + * If you change the conditions under which rel locks are acquired + * here, be sure to adjust ExecOpenScanRelation to match. + */ switch (rc->markType) { case ROW_MARK_EXCLUSIVE: -- cgit v1.2.3