Re: LockHasWaiters() crashes on fast-path locks

On Tue, Jul 14, 2026 at 11:02:56AM -0400, Robert Haas wrote:
> On Thu, Mar 26, 2026 at 7:06 PM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> > Thanks for sending the updated patch. It looks good to me. I verified
> > it with the other thread patch - it fixes the SEGV.
>
> To me, it seems like a bad idea for LockHasWaiters() to have the side
> effect of adding entries to the main lock table. If nobody else has
> moved our lock into the main lock table, it has no waiters. I think we
> should just search LockMethodProcLockHash and see if we find anything,
> and if not, return false without moving the lock.
>
> Alternatively, if we don't need the functionality for anything, we
> might just want LockHasWaiters() to assert
> !EligibleForRelationFastPath(), and document the problem in a comment.

In terms of the core code, that's a true statement. Honestly, I would
be tempted to just add an assert and a comment and call it a day. I
don't see a strong need to support this case if we have nothing in
core to test it and nothing in core that needs it, and there are no
facts that we need to do anything. If there are optimizations in core
that could make use of it, and perhaps there are, that would make the
case of this proposal easier to support, at least that's my
impression. Without such cases in mind, this proposal feels mostly
like dead code to me.

Perhaps out-of-core code or extensions could make use of this API, but
in my experience this usually points at possible optimizations in the
backend core code. I'd suggest to look at that first, perhaps, if
you'd like to make LockHasWaiters() fast-path safe?
--
Michael