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
Description: Binary data
