public inbox for [email protected]
help / color / mirror / Atom feedFrom: SATYANARAYANA NARLAPURAM <[email protected]>
To: Bharath Rupireddy <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: LockHasWaiters() crashes on fast-path locks
Date: Thu, 26 Mar 2026 14:53:57 -0700
Message-ID: <CAHg+QDfH5ZD7-wEdMc4bS4-A=N3bymy0ckHXUHOwrN-bE9AmXw@mail.gmail.com> (raw)
In-Reply-To: <CAHg+QDc4f8hEEXODN5H=ETfOzg9QqaPW17=W_jYtXQUcAwZ84A@mail.gmail.com>
References: <CAHg+QDe_=ZahnRx37bzrqYenKn_S5YDQ00fTfwe-ZUmjqO=qLg@mail.gmail.com>
<CALj2ACUKM1KQC=NHESOJw=ZgjAXgxapJfAEovKN0n3ZF8Csr5w@mail.gmail.com>
<CAHg+QDc4f8hEEXODN5H=ETfOzg9QqaPW17=W_jYtXQUcAwZ84A@mail.gmail.com>
Updated the patch with a commit message.
On Wed, Mar 25, 2026 at 3:34 PM SATYANARAYANA NARLAPURAM <
[email protected]> wrote:
> Hi,
>
> On Wed, Mar 25, 2026 at 3:06 PM Bharath Rupireddy <
> [email protected]> wrote:
>
>> Hi,
>>
>> On Wed, Mar 25, 2026 at 2:15 PM SATYANARAYANA NARLAPURAM
>> <[email protected]> wrote:
>> >
>> > Hi Hackers,
>> >
>> > 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 locks (< ShareUpdateExclusiveLock) on
>> relations may not be stored in the shared lock hash table, and the
>> LOCALLOCK entry is left with lock = NULL and proclock = NULL in such a case.
>> >
>> > If LockHasWaiters() is called for such a lock, it dereferences those
>> NULL pointers when it reads proclock->holdMask and lock->waitMask, causing
>> a segfault.
>> >
>> > The only existing caller is lazy_truncate_heap() in VACUUM, which
>> queries LockHasWaitersRelation(rel, AccessExclusiveLock). Since
>> AccessExclusiveLock is the strongest lock level, it is never fast-pathed,
>> so the bug has never been triggered in practice. However, any new caller
>> that passes a weak lock mode, for example, checking whether a DDL is
>> waiting on an AccessShareLock will crash. The fix is to transfer the lock
>> to the main lock table before we access them.
>> >
>> > Attached a patch to address this issue.
>>
>> Nice find! It would be good to add a test case (perhaps in an existing
>> test extension even though we may not commit it; it can act as a
>> demo).
>>
>
> Please refer the patches in the thread [2] below for a repro / use case.
>
>
>>
>> I see that this type of lock transfer is happening for prepared
>> statements (see AtPrepare_Locks [1]). However, I see the proposed
>> patch relying on lock == NULL for detecting whether the lock was
>> acquired using fast-path. Although this looks correct because if the
>> lock or proclock pointers are NULL, this identifies that the lock was
>> taken using fast-path. But for consistency purposes, can we have the
>> same check as that of AtPrepare_Locks?
>
>
> Thank you for the review and code pointer, this is addressed now in v2
> patch, attached.
>
> [2]
> https://www.postgresql.org/message-id/CAHg%2BQDfdoR%3D7iqEAvLW9qtzV0Sx1wp2FuALeamqcCdiVEmMF-Q%40mail...
>
>
> Thanks,
> Satya
>
Attachments:
[application/octet-stream] v3-0001-Fix-LockHasWaiters-crash-for-fast-path-locks.patch (1.8K, 3-v3-0001-Fix-LockHasWaiters-crash-for-fast-path-locks.patch)
download | inline diff:
From 349f3fa56abda1f9411400ae9a05efabcb2270e8 Mon Sep 17 00:00:00 2001
From: Satya Narlapuram <[email protected]>
Date: Thu, 26 Mar 2026 21:42:15 +0000
Subject: [PATCH] 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 (< 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.
Fix by checking whether the LOCALLOCK has been populated and, if not,
calling FastPathGetRelationLockEntry() to transfer the lock from the
fast-path arrays into the main lock table.
---
src/backend/storage/lmgr/lock.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index d930c66c..3f4d343d 100644
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -743,6 +743,17 @@ LockHasWaiters(const LOCKTAG *locktag, LOCKMODE lockmode, bool sessionLock)
*/
partitionLock = LockHashPartitionLock(locallock->hashcode);
+ /*
+ * If the local lock was taken via the fast-path, we need to move it
+ * to the primary lock table, or just get a pointer to the existing
+ * primary lock table entry if by chance it's already been transferred.
+ */
+ if (locallock->proclock == NULL)
+ {
+ locallock->proclock = FastPathGetRelationLockEntry(locallock);
+ locallock->lock = locallock->proclock->tag.myLock;
+ }
+
LWLockAcquire(partitionLock, LW_SHARED);
/*
--
2.43.0
view thread (5+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: LockHasWaiters() crashes on fast-path locks
In-Reply-To: <CAHg+QDfH5ZD7-wEdMc4bS4-A=N3bymy0ckHXUHOwrN-bE9AmXw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox