Fix corner case where SELECT FOR UPDATE could return a row twice.

tglsfdc · tglsfdc · commit f5e4e92fbe2f · 2014-12-11T19:37:17.000-05:00
In READ COMMITTED mode, if a SELECT FOR UPDATE discovers it has to redo
WHERE-clause checking on rows that have been updated since the SELECT's
snapshot, it invokes EvalPlanQual processing to do that.  If this first
occurs within a non-first child table of an inheritance tree, the previous
coding could accidentally re-return a matching row from an earlier,
already-scanned child table.  (And, to add insult to injury, I think this
could make it miss returning a row that should have been returned, if the
updated row that this happens on should still have passed the WHERE qual.)
Per report from Kyotaro Horiguchi; the added isolation test is based on his
test case.

This has been broken for quite awhile, so back-patch to all supported
branches.
diff --git a/src/backend/executor/nodeLockRows.c b/src/backend/executor/nodeLockRows.c
@@ -160,7 +160,29 @@ ExecLockRows(LockRowsState *node)
 				 */
 				if (!epq_started)
 				{
+					ListCell   *lc2;
+
 					EvalPlanQualBegin(&node->lr_epqstate, estate);
+
+					/*
+					 * Ensure that rels with already-visited rowmarks are told
+					 * not to return tuples during the first EPQ test.  We can
+					 * exit this loop once it reaches the current rowmark;
+					 * rels appearing later in the list will be set up
+					 * correctly by the EvalPlanQualSetTuple call at the top
+					 * of the loop.
+					 */
+					foreach(lc2, node->lr_arowMarks)
+					{
+						ExecAuxRowMark *aerm2 = (ExecAuxRowMark *) lfirst(lc2);
+
+						if (lc2 == lc)
+							break;
+						EvalPlanQualSetTuple(&node->lr_epqstate,
+											 aerm2->rowmark->rti,
+											 NULL);
+					}
+
 					epq_started = true;
 				}
 
