Horton
Menu

Re: ri_LockPKTuple misleading message

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Junwang Zhao <zhjwpku@gmail.com>, jian he <jian.universality@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-04-25T13:38:10Z
Lists: pgsql-hackers 
Hi,

On 2026-04-25 20:59:50 +0900, Amit Langote wrote:
> 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>
> > 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.

Greetings,

Andres Freund

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use "concurrent delete" in serialization error for TM_Deleted cases

  2. Add fast path for foreign key constraint checks