Thread

  1. Re: ri_LockPKTuple misleading message

    amit <amitlangote09@gmail.com> — 2026-05-01T01:13:57Z

    On Tue, Apr 28, 2026 at 2:58 PM Amit Langote <amitlangote09@gmail.com> wrote:
    > On Mon, Apr 27, 2026 at 1:51 PM Amit Langote <amitlangote09@gmail.com> wrote:
    > > On Sat, Apr 25, 2026 at 10:38 PM Andres Freund <andres@anarazel.de> wrote:
    > > > 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.
    > >
    > > 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.
    >
    > New version where I added a test case to the isolation suite that
    > exercises ri_LockPKTuple().
    >
    > Will push barring objections.
    
    Done.
    
    -- 
    Thanks, Amit Langote