Use "concurrent delete" in serialization error for TM_Deleted cases
Amit Langote <amitlan@postgresql.org>
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 <jian.universality@gmail.com> Author: Amit Langote <amitlangote09@gmail.com> Reviewed-by: Junwang Zhao <zhjwpku@gmail.com> Discussion: https://postgr.es/m/CACJufxEG1JTCq4A1gnNAu-bGAq9Xn=Xkf7kC3TRWFz6iuUOuRA@mail.gmail.com
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/executor/nodeLockRows.c | modified | +1 −1 |
| src/backend/utils/adt/ri_triggers.c | modified | +1 −1 |
| src/test/isolation/expected/fk-concurrent-pk-upd.out | modified | +20 −0 |
| src/test/isolation/expected/fk-partitioned-2.out | modified | +2 −2 |
| src/test/isolation/expected/fk-snapshot-2.out | modified | +2 −2 |
| src/test/isolation/expected/fk-snapshot-3.out | modified | +2 −2 |
| src/test/isolation/specs/fk-concurrent-pk-upd.spec | modified | +3 −0 |
Discussion
- ri_LockPKTuple misleading message 8 messages · 2026-04-25 → 2026-05-01