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]> > wrote: > > > > On Sat, Apr 25, 2026 at 19:53 jian he <[email protected]> > 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>
