On Mon, Apr 27, 2026 at 1:51 PM Amit Langote <[email protected]> wrote: > On Sat, Apr 25, 2026 at 10:38 PM Andres Freund <[email protected]> wrote: > > On 2026-04-25 20:59:50 +0900, Amit Langote wrote: > > > On Sat, Apr 25, 2026 at 20:42 Junwang Zhao <[email protected]> wrote: > > > > > > > On Sat, Apr 25, 2026 at 7:31 PM Amit Langote <[email protected]> > > > > I have a feeling we should also update ExecLockRows(), since the > > > > TM_Deleted branches in other places seem to use the wording > > > > "concurrent delete". > > > > > > > > cc andres since he was the original author of this code. > > > > > > > > > > > > https://github.com/postgres/postgres/blob/REL_12_STABLE/src/backend/executor/nodeLockRows.c#L230 > > > > > > Ah, OK, then let's change both instances for consistency, unless Andres > > > remembers a reason not to. > > > > > > Thanks Junwang for checking that. > > > > No, I can't see any reason for that. I assume it was a copy & paste error, > > but it's hard to know this far back. > > Thanks for chiming in. > > Here is a patch to fix both instances. I'll leave the ExecLockRows() > instances unchanged in the back-branches due to the lack of user > complaints.
New version where I added a test case to the isolation suite that exercises ri_LockPKTuple(). Will push barring objections. -- Thanks, Amit Langote
v2-0001-Use-concurrent-delete-in-serialization-error-for-.patch
Description: Binary data
