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

> On Feb 28, 2026, at 04:38, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> 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
> <0001-libpq-Add-PQgetThreadLock-to-mirror-PQregisterThread.patch>

I wonder instead of exposing the lock itself, would it be cleaner to add a pair of Lock/Unlock APIs?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/