| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: LockHasWaiters() crashes on fast-path locks |
| Date: | 2026-07-14 15:02:56 |
| Message-ID: | CA+Tgmob3mVc0LgKNtgy-MdDd9KLffzw1X=9qR8UaRmON0xJWNA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2026-07-14 15:05:26 | Re: document the dangers of granting TRIGGER or REFERENCES |
| Previous Message | vignesh C | 2026-07-14 14:51:45 | Re: Include sequences in publications created by pg_createsubscriber |