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.
Branch
------
REL9_3_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/f14196c3597364f3562e65bf869f7942fc9188b4
Modified Files
--------------
src/backend/executor/nodeLockRows.c | 22 ++++++++++++++++++++++
src/test/isolation/expected/eval-plan-qual.out | 23 +++++++++++++++++++++++
src/test/isolation/specs/eval-plan-qual.spec | 16 ++++++++++++++++
3 files changed, 61 insertions(+)