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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: [PATCH] Add PQgetThreadLock() to expose the Kerberos/Curl mutex
Date: 2026-02-27 20:38:34
Message-ID: CAOYmi+=MHD+WKD4rsTn0v8220mYfyLGhEc5EfhmtqrAb7SmC5g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
0001-libpq-Add-PQgetThreadLock-to-mirror-PQregisterThread.patch application/octet-stream 4.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-02-27 22:46:21 Re: pg_plan_advice
Previous Message Tom Lane 2026-02-27 20:21:02 Re: Optimize SELECT * in EXISTS