aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/jsonfuncs.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-03-22 17:56:06 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-03-22 17:56:20 -0400
commit71404af2a29ce4a3a5907cdc8b893ec2bc0285b4 (patch)
tree875e6859c394a4f32c770bddab3d3069e457a12e /src/backend/utils/adt/jsonfuncs.c
parentf6bd0da63bf40bc324eec6fd47f3d3d301f44dab (diff)
downloadpostgresql-71404af2a29ce4a3a5907cdc8b893ec2bc0285b4.tar.gz
postgresql-71404af2a29ce4a3a5907cdc8b893ec2bc0285b4.zip
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.
Diffstat (limited to 'src/backend/utils/adt/jsonfuncs.c')
0 files changed, 0 insertions, 0 deletions