MIME-Version: 1.0
From: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Date: Wed, 25 Mar 2026 14:15:08 -0700
Message-ID: 
 <CAHg+QDe_=ZahnRx37bzrqYenKn_S5YDQ00fTfwe-ZUmjqO=qLg@mail.gmail.com>
Subject: LockHasWaiters() crashes on fast-path locks
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000ea42bd064ddfc39c"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHg%2BQDe_%3DZahnRx37bzrqYenKn_S5YDQ00fTfwe-ZUmjqO%3DqLg%40mail.gmail.com>
Precedence: bulk

--000000000000ea42bd064ddfc39c
Content-Type: multipart/alternative; boundary="000000000000ea42bc064ddfc39a"

--000000000000ea42bc064ddfc39a
Content-Type: text/plain; charset="UTF-8"

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.


Thanks,
Satya

--000000000000ea42bc064ddfc39a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Hackers,</div><div><br></div>LockHasWaiters() assu=
mes that the LOCALLOCK&#39;s lock and proclock pointers are populated, but =
this is not the case for locks acquired via the fast-path optimization. Wea=
k locks (&lt; ShareUpdateExclusiveLock) on relations may not be stored in t=
he shared lock hash table, and the LOCALLOCK entry is left with lock =3D NU=
LL and proclock =3D NULL in such a case.<br><br>If LockHasWaiters() is call=
ed for such a lock, it dereferences those NULL pointers when it reads procl=
ock-&gt;holdMask and lock-&gt;waitMask, causing a segfault.<br><br>The only=
 existing caller is lazy_truncate_heap() in VACUUM, which queries LockHasWa=
itersRelation(rel, AccessExclusiveLock). Since AccessExclusiveLock is the s=
trongest lock level, it is never fast-pathed, so the bug has never been tri=
ggered in practice. However, any new caller that passes a weak lock mode, f=
or example, checking whether a DDL is waiting on an AccessShareLock will cr=
ash. The fix is to transfer the lock to the main lock table before we acces=
s them.<div><br></div><div>Attached a patch to address this issue.=C2=A0</d=
iv><div><br></div><div><br><div>Thanks,</div><div>Satya</div></div></div>

--000000000000ea42bc064ddfc39a--

--000000000000ea42bd064ddfc39c
Content-Type: application/octet-stream;
	name="0001-lock-has-waiters-fast-path-fix.patch"
Content-Disposition: attachment;
	filename="0001-lock-has-waiters-fast-path-fix.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mn6jj7n90>
X-Attachment-Id: f_mn6jj7n90

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3N0b3JhZ2UvbG1nci9sb2NrLmMgYi9zcmMvYmFja2Vu
ZC9zdG9yYWdlL2xtZ3IvbG9jay5jCmluZGV4IGQ5MzBjNjZjLi5mZjliOWNhYSAxMDA2NDQKLS0t
IGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9sbWdyL2xvY2suYworKysgYi9zcmMvYmFja2VuZC9zdG9y
YWdlL2xtZ3IvbG9jay5jCkBAIC03NDMsNiArNzQzLDIwIEBAIExvY2tIYXNXYWl0ZXJzKGNvbnN0
IExPQ0tUQUcgKmxvY2t0YWcsIExPQ0tNT0RFIGxvY2ttb2RlLCBib29sIHNlc3Npb25Mb2NrKQog
CSAqLwogCXBhcnRpdGlvbkxvY2sgPSBMb2NrSGFzaFBhcnRpdGlvbkxvY2sobG9jYWxsb2NrLT5o
YXNoY29kZSk7CiAKKwkvKgorCSAqIElmIHRoZSBsb2NrIHdhcyBhY3F1aXJlZCB2aWEgdGhlIGZh
c3QgcGF0aCwgbG9jYWxsb2NrLT5sb2NrIGFuZAorCSAqIGxvY2FsbG9jay0+cHJvY2xvY2sgd2ls
bCBiZSBOVUxMLiAgV2UgbXVzdCB0cmFuc2ZlciB0aGUgbG9jayB0byB0aGUKKwkgKiBtYWluIGxv
Y2sgdGFibGUgYmVmb3JlIHdlIGNhbiBpbnNwZWN0IExPQ0stPndhaXRNYXNrLgorCSAqLworCWlm
IChsb2NhbGxvY2stPmxvY2sgPT0gTlVMTCkKKwl7CisJCVBST0NMT0NLICAgKmZwX3Byb2Nsb2Nr
OworCisJCWZwX3Byb2Nsb2NrID0gRmFzdFBhdGhHZXRSZWxhdGlvbkxvY2tFbnRyeShsb2NhbGxv
Y2spOworCQlsb2NhbGxvY2stPmxvY2sgPSBmcF9wcm9jbG9jay0+dGFnLm15TG9jazsKKwkJbG9j
YWxsb2NrLT5wcm9jbG9jayA9IGZwX3Byb2Nsb2NrOworCX0KKwogCUxXTG9ja0FjcXVpcmUocGFy
dGl0aW9uTG9jaywgTFdfU0hBUkVEKTsKIAogCS8qCg==
--000000000000ea42bd064ddfc39c--