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_1_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/21946ac9b61bbd3257449ce7ad511618e1a5d695 Modified Files -------------- src/backend/executor/nodeLockRows.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
