Use "concurrent delete" in serialization error for TM_Deleted cases
In ExecLockRows() and ri_LockPKTuple(), the TM_Deleted code path was using the same "could not serialize access due to concurrent update" message as the TM_Updated path. Use "concurrent delete" instead, since the tuple was deleted, not updated. The ExecLockRows() instance was likely a copy-paste error per Andres; the ri_LockPKTuple() instance was carried over from the same pattern in commit 2da86c1ef9. Update affected isolation test expected files accordingly and add a new test to fk-concurrent-pk-upd.spec with concurrent delete of the PK row. The ExecLockRows() change is master-only for lack of user complaints and to avoid breaking anything that might match on the error text. Reported-by: Jian He <[email protected]> Author: Amit Langote <[email protected]> Reviewed-by: Junwang Zhao <[email protected]> Discussion: https://postgr.es/m/CACJufxEG1JTCq4A1gnNAu-bGAq9Xn=xkf7kc3trwfz6iuuo...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/410013d2a5917ee8978c944e582e323acc9ebdcf Modified Files -------------- src/backend/executor/nodeLockRows.c | 2 +- src/backend/utils/adt/ri_triggers.c | 2 +- src/test/isolation/expected/fk-concurrent-pk-upd.out | 20 ++++++++++++++++++++ src/test/isolation/expected/fk-partitioned-2.out | 4 ++-- src/test/isolation/expected/fk-snapshot-2.out | 4 ++-- src/test/isolation/expected/fk-snapshot-3.out | 4 ++-- src/test/isolation/specs/fk-concurrent-pk-upd.spec | 3 +++ 7 files changed, 31 insertions(+), 8 deletions(-)
