Commits on Aug 21, 2026
-
Fix LockHasWaiters() crash for fast-path locks.
LockHasWaiters() assumes that the LOCALLOCK's lock and proclock pointers are populated, but this is not the case for locks acquired via the fast-path optimization. Weak relation locks (those below ShareUpdateExclusiveLock, including AccessShareLock) are not stored in the shared lock hash table, leaving the LOCALLOCK entry with lock = NULL and proclock = NULL. If LockHasWaiters() is called for such a lock, it dereferences those NULL pointers when reading proclock->holdMask and lock->waitMask, causing a segfault. Having LockHasWaiters() transfer the lock into the main lock table with FastPathGetRelationLockEntry() would avoid the crash, but that gives a read-only check the side effect of adding entries to the main lock table. It is also unnecessary, because if nobody else has moved our lock into the main lock table, it has no waiters. Fix by looking up the main lock table when the LOCALLOCK pointers are NULL. If no entry is found, the lock is still held via the fast path and cannot have any waiters, so we return false without moving it. If an entry is found, some backend already transferred the lock, and we re-find the lock and proclock as LockRelease() does. Reported-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com> Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Co-authored-by: Satyanarayana Narlapuram <satyanarlapuram@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHg%2BQDe_%3DZahnRx37bzrqYenKn_S5YDQ00fTfwe-ZUmjqO%3DqLg%40mail.gmail.com
2 people authored and committed
Aug 21, 2026