Fix corner case where SELECT FOR UPDATE could return a row twice.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 12 Dec 2014 00:37:17 +0000 (19:37 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 12 Dec 2014 00:37:17 +0000 (19:37 -0500)
commitf5e4e92fbe2fd655d8b1ec30b523cfb134e66bf0
tree34ad1cf370e485df316067acf252f1caeb5ff790
parentd67be559ed8a43248c11f165d70b9dfd6439bb61
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.
src/backend/executor/nodeLockRows.c