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
forExecLockRows(), 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
>
> - Amit
--
Regards
Junwang Zhao
