MIME-Version: 1.0
References: 
 <CAHg+QDe_=ZahnRx37bzrqYenKn_S5YDQ00fTfwe-ZUmjqO=qLg@mail.gmail.com>
In-Reply-To: 
 <CAHg+QDe_=ZahnRx37bzrqYenKn_S5YDQ00fTfwe-ZUmjqO=qLg@mail.gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Wed, 25 Mar 2026 15:06:14 -0700
Message-ID: 
 <CALj2ACUKM1KQC=NHESOJw=ZgjAXgxapJfAEovKN0n3ZF8Csr5w@mail.gmail.com>
Subject: Re: LockHasWaiters() crashes on fast-path locks
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALj2ACUKM1KQC%3DNHESOJw%3DZgjAXgxapJfAEovKN0n3ZF8Csr5w%40mail.gmail.com>
Precedence: bulk

Hi,

On Wed, Mar 25, 2026 at 2:15=E2=80=AFPM SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com> 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-pat=
h optimization. Weak locks (< ShareUpdateExclusiveLock) on relations may no=
t be stored in the shared lock hash table, and the LOCALLOCK entry is left =
with lock =3D NULL and proclock =3D 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 se=
gfault.
>
> The only existing caller is lazy_truncate_heap() in VACUUM, which queries=
 LockHasWaitersRelation(rel, AccessExclusiveLock). Since AccessExclusiveLoc=
k is the strongest lock level, it is never fast-pathed, so the bug has neve=
r been triggered in practice. However, any new caller that passes a weak lo=
ck mode, for example, checking whether a DDL is waiting on an AccessShareLo=
ck will crash. The fix is to transfer the lock to the main lock table befor=
e 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).

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 =3D=3D 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?

[1]
/*
* 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 =3D=3D NULL)

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