| From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
|---|---|
| To: | jian he <jian(dot)universality(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ri_LockPKTuple misleading message |
| Date: | 2026-04-25 11:31:07 |
| Message-ID: | CA+HiwqF81hJcW-A2MQ1vuHDxhkR-qGMd5gY36wHKyQM-99W+iQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
- Amit
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Junwang Zhao | 2026-04-25 11:42:27 | Re: ri_LockPKTuple misleading message |
| Previous Message | jian he | 2026-04-25 10:52:52 | ri_LockPKTuple misleading message |