| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Nico Williams <nico(at)cryptonector(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Add PQgetThreadLock() to expose the Kerberos/Curl mutex |
| Date: | 2026-03-02 17:37:32 |
| Message-ID: | CAOYmi+=3f3JK9wjV7Sq3uDO8n6cn3wY5ZmZ0cWc3DgKzgy8UDQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 27, 2026 at 7:13 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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(at)cryptonector(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-03-02 17:49:59 | Re: [PATCH] pg_get_domain_ddl: DDL reconstruction function for CREATE DOMAIN statement |
| Previous Message | Álvaro Herrera | 2026-03-02 17:33:39 | Re: [PATCH] psql: tab completion for ALTER ROLE ... IN DATABASE ... |