Re: LockHasWaiters() crashes on fast-path locks

Hi,

On Tue, Jul 14, 2026 at 8:03 AM Robert Haas <robertmhaas(at)gmail(dot)com> 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.

Thanks Satya for the off-list discussion, and thanks Robert for the review.

> 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.

Agreed. A fast-path lock can only get a waiter if some backend asks
for a conflicting lock, and in LockAcquireExtended() that backend
first calls FastPathTransferRelationLocks() to move the matching
fast-path locks into LockMethodLockHash and LockMethodProcLockHash
before it waits. So if we look there and find nothing, the lock still
has no waiters, and we can just return false without moving it.
Attached v4 patch implements this.

> 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.

The autoprewarm yielding to concurrent DDL work, which calls
LockHasWaiters() for an AccessShareLock (which is fast-path), needs
this fix. https://www.postgresql.org/message-id/flat/CAHg%2BQDfdoR%3D7iqEAvLW9qtzV0Sx1wp2FuALeamqcCdiVEmMF-Q%40mail.gmail.com

Please review the attached v4 patch.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com