Re: ri_LockPKTuple misleading message

On Sat, Apr 25, 2026 at 20:42 Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:

> On Sat, Apr 25, 2026 at 7:31 PM Amit Langote <amitlangote09(at)gmail(dot)com>
> wrote:
> >
> > On Sat, Apr 25, 2026 at 19:53 jian he <jian(dot)universality(at)gmail(dot)com>
> wrote:
> >>
> >> Hi.
> >>
> >>
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=2da86c1ef9b5446e0e22c0b6a5846293e58d98e3
> >> + case TM_Deleted:
> >> + if (IsolationUsesXactSnapshot())
> >> + ereport(ERROR,
> >> + (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
> >> + errmsg("could not serialize access due to concurrent update")));
> >>
> >> errmsg should be
> >> errmsg("could not serialize access due to concurrent delete")));
> >> ?
> >>
> >> ExecLockRows also has the same situation.
> >
> >
> > I guess the existing wording may have been using "concurrent update" in
> the broader sense of "concurrent modification" of the tuple, so I'm not
> sure that it's just an oversight.
> >
> > That said, "concurrent delete" is more precise for the TM_Deleted case,
> so I'll change it in the code I committed. As for ExecLockRows(), I'll
> > leave that alone unless others think we should change that too.
>
> 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.

- Amit

>
> <https://github.com/postgres/postgres/blob/REL_12_STABLE/src/backend/executor/nodeLockRows.c#L230>