On Sat, Apr 25, 2026 at 20:42 Junwang Zhao <zhjwpku@gmail.com> wrote:
On Sat, Apr 25, 2026 at 7:31 PM Amit Langote <amitlangote09@gmail.com> wrote: > > On Sat, Apr 25, 2026 at 19:53 jian he <jian.universality@gmail.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.
