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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Fix EvalPlanQual bug when query contains both locked and not-loc
Дата
Msg-id E1aiUI1-0001wL-Jh@gemulon.postgresql.org
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Fix EvalPlanQual bug when query contains both locked and not-loc
Следующее
От: Simon Riggs
Дата:
Сообщение: pgsql: Change comment to describe correct lock level used