| 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 |
| 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 |