Re: ri_LockPKTuple misleading message

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Junwang Zhao <zhjwpku(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ri_LockPKTuple misleading message
Date: 2026-04-27 04:51:38
Message-ID: CA+HiwqGF_myog4OcQ+39CnFzS8iODS+YeGDNw9UfU_OxyNjvcA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Andres,

On Sat, Apr 25, 2026 at 10:38 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2026-04-25 20:59:50 +0900, Amit Langote wrote:
> > 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>
> > > 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.
>
> No, I can't see any reason for that. I assume it was a copy & paste error,
> but it's hard to know this far back.

Thanks for chiming in.

Here is a patch to fix both instances. I'll leave the ExecLockRows()
instances unchanged in the back-branches due to the lack of user
complaints.

--
Thanks, Amit Langote

Attachment Content-Type Size
v1-0001-Use-concurrent-delete-in-serialization-error-for-.patch application/octet-stream 5.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-04-27 04:52:43 Re: Row pattern recognition
Previous Message Hayato Kuroda (Fujitsu) 2026-04-27 04:46:37 RE: Adding REPACK [concurrently]