On Tue, Jul 14, 2026 at 11:02:56AM -0400, Robert Haas wrote: > On Thu, Mar 26, 2026 at 7:06 PM Bharath Rupireddy > <[email protected]> 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
signature.asc
Description: PGP signature
