From: Tom Lane Date: Fri, 12 Dec 2014 00:37:14 +0000 (-0500) Subject: Fix corner case where SELECT FOR UPDATE could return a row twice. X-Git-Tag: REL9_1_15~57 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=21946ac9b61bbd3257449ce7ad511618e1a5d695;p=postgresql Fix corner case where SELECT FOR UPDATE could return a row twice. 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 index 6f5c2d2290..6fac96197b 100644 --- a/src/backend/executor/nodeLockRows.c +++ b/src/backend/executor/nodeLockRows.c @@ -160,7 +160,29 @@ lnext: */ 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; }