Subject: [PATCH] Add PQgetThreadLock() to expose the Kerberos/Curl mutex

From: Jacob Champion <[email-masked]>
Date: Fri, 27 Feb 2026 12:38:34 -0800

Hello all,

libpq has some third-party dependencies (currently, Kerberos and Curl)
that aren't threadsafe in some situations. We protect the affected
code with a locking callback, and we allow applications to override
that callback globally because they might also be using those
third-party dependencies. The history of the API is at [1, 2].

That appears to work well enough for clients that control the main()
function. With OAuth, there are use cases where third-party code
living "behind" libpq (i.e. in libraries invoked via callbacks) may
need to make use of the threadlock as well. So this patch just adds a
getter API. libpq-oauth would be the first client of the new function
for PG19.

This doesn't actually expose any net-new internals:
PQregisterThreadLock() already returned the previous function pointer
to the caller, but that can't be used by a library that just wants to
*use* the existing lock without modifying it.

Best I can tell, the setter has always been unsafe for concurrent use
(it's madness to change the locking callback while a connection might
be using it, right?), so I've noted this explicitly in the
documentation.

Any objections?

Thanks!
--Jacob

[1] https://postgr.es/m/3FB943E4.90508%40colorfullife.com
[2] https://postgr.es/m/4001594F.6060304%40colorfullife.com