pgsql: Fix EvalPlanQual bug when query contains both locked and not-loc - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Fix EvalPlanQual bug when query contains both locked and not-loc
Date
Msg-id E1aiUI1-0001wL-Jh@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix EvalPlanQual bug when query contains both locked and not-locked rels.

In commit afb9249d06f47d7a, we (probably I) made ExecLockRows assign
null test tuples to all relations of the query while setting up to do an
EvalPlanQual recheck for a newly-updated locked row.  This was sheerest
brain fade: we should only set test tuples for relations that are lockable
by the LockRows node, and in particular empty test tuples are only sensible
for inheritance child relations that weren't the source of the current
tuple from their inheritance tree.  Setting a null test tuple for an
unrelated table causes it to return NULLs when it should not, as exhibited
in bug #14034 from Bronislav Houdek.  To add insult to injury, doing it the
wrong way required two loops where one would suffice; so the corrected code
is even a bit shorter and faster.

Add a regression test case based on his example, and back-patch to 9.5
where the bug was introduced.

Branch
------
REL9_5_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/d8d5a00b182009f6fdb426a40ac677c4fda56be7

Modified Files
--------------
src/backend/executor/nodeLockRows.c            | 40 ++++++++++++--------------
src/test/isolation/expected/eval-plan-qual.out | 19 ++++++++++++
src/test/isolation/specs/eval-plan-qual.spec   | 23 +++++++++++++++
3 files changed, 60 insertions(+), 22 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Fix EvalPlanQual bug when query contains both locked and not-loc
Next
From: Simon Riggs
Date:
Subject: pgsql: Change comment to describe correct lock level used