Fix bug in following update chain when locking a heap tuple After waiting for a concurrent updater to finish, heap_lock_tuple() followed the update chain to lock all tuple versions. However, when stepping from the initial tuple to the next one, it failed to check that the next tuple's XMIN matches the initial tuple's XMAX. That's an important check whenever following an update chain, and the recursive part that follows the chain did it, but the initial step missed it. Without the check, if the updating transaction aborts, the updated tuple is vacuumed away and replaced by an unrelated tuple, the unrelated tuple might get incorrectly locked.
Author: Jasper Smit <[email protected]> Discussion: https://www.postgresql.org/message-id/CAOG+RQ74x0q=kgBBQ=mezuvoezbfsxm1qu_o0v28bwdz3dh...@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bb87d7fef1031b03e7595c05ef83f38d1df29028 Modified Files -------------- src/backend/access/heap/heapam.c | 48 ++++++--- src/test/modules/injection_points/Makefile | 4 +- .../injection_points/expected/heap_lock_update.out | 83 +++++++++++++++ src/test/modules/injection_points/meson.build | 1 + .../injection_points/specs/heap_lock_update.spec | 117 +++++++++++++++++++++ 5 files changed, 237 insertions(+), 16 deletions(-)
