Re: [PATCH] Add PQgetThreadLock() to expose the Kerberos/Curl mutex
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Nico Williams <nico@cryptonector.com>, Chao Li <li.evan.chao@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-02T17:37:32Z
Lists: pgsql-hackers
On Fri, Feb 27, 2026 at 7:13 PM Chao Li <li.evan.chao@gmail.com> wrote: > I wonder instead of exposing the lock itself, would it be cleaner to add a pair of Lock/Unlock APIs? The lock is *already* exposed. For better or worse, this is the API we've chosen. And since the need for the lock will hopefully decrease over time, I don't think we should put effort into improving it. On Fri, Feb 27, 2026 at 8:40 PM Nico Williams <nico@cryptonector.com> wrote: > Well, that's ancient stuff. krb4? 4?! > > Anyways, I'm quite curious about any thread safety problems you are > aware of in Kerberos implementations today. Ha, I'd wondered how much of the documentation (and locking) around this was relevant in 2026. Not something I plan to tackle in the near future, though :D > As for curl, it wants to be > initialized much like OpenSSL used to want to be initialized (thankfully > no more), and that's a problem. Curl is also in the "thankfully no more" bucket, but we support older Red Hat installations that don't have the improvement yet. Thanks, --Jacob
Commits
-
libpq: Add PQgetThreadLock() to mirror PQregisterThreadLock()
- b8d76858353e 19 (unreleased) landed