Fix RETURNING OLD with BEFORE UPDATE trigger and concurrent update. When executing an UPDATE with a RETURNING clause on a table with a BEFORE UPDATE row trigger, the computation of the OLD values in the RETURNING list was incorrect if the target tuple was concurrently updated by another session, at isolation level READ COMMITTED.
The problem was that the trigger code would lock the target tuple, waiting for the other session to commit, and then fetch the updated target tuple, but ExecUpdate() would not realise that the target tuple had changed, and use the outdated target tuple for computing OLD values. Fix by having ExecUpdate() check the TM_FailureData from trigger execution and re-fetch the target tuple if necessary. Re-fetching the target tuple like this is a little inefficient, but probably negligible compared to the trigger execution and update. A better long-term fix might be to move the EPQ code out of trigger.c, and let ExecUpdate() handle it, like ExecMergeMatched() does, but that would likely mean changing the trigger API, which seems a bit much for back-patching. Backpatch to v18, where support for RETURNING OLD/NEW was added. Bug: #19536 Reported-by: Jonas Boberg <[email protected]> Diagnosed-by: Bharath Rupireddy <[email protected]> Author: Dean Rasheed <[email protected]> Reviewed-by: Bharath Rupireddy <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 18 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7048e50f8f93057128db7e8a0a2925248f71a266 Modified Files -------------- src/backend/executor/nodeModifyTable.c | 19 ++ .../isolation/expected/eval-plan-qual-trigger.out | 258 ++++++++++----------- .../isolation/expected/merge-match-recheck.out | 179 ++++++++++++-- .../isolation/specs/eval-plan-qual-trigger.spec | 8 +- src/test/isolation/specs/merge-match-recheck.spec | 21 +- 5 files changed, 333 insertions(+), 152 deletions(-)
