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

2 files changed, 7 insertions, 1 deletions

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 99f7a049930..315a555dcff 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -807,6 +807,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:
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index 8b341dae4ed..c4d048f4216 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -820,7 +820,9 @@ ExecOpenScanRelation(EState *estate, Index scanrelid, int eflags)
 		{
 			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;