Re: libpq OpenSSL and multithreading

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-29T09:41:17Z
Lists: pgsql-hackers
On 22.10.25 10:59, Daniel Gustafsson wrote:
>> On 1 Sep 2025, at 07:27, Peter Eisentraut <peter@eisentraut.org> wrote:
> 
>> I suggest that instead of adding the context to the Port structure, make a separate context struct for this purpose, for example:
> 
> Fair enough, done in the attached.

This looks good to me.  (I would not have the CallbackErr typedef, since 
that additional abstraction doesn't buy anything.  But it's a small 
difference.)

>> This seems like an extremely inconvenient solution, as can be seen by the amount of changes your patch introduces.  We could just make errbuf thread-local and be done, without having to change the API.  (This is how glibc's strerror() works internally.)
> 
> I assume you mean simply leaving it be for now awaiting more thread primitives
> to be added to fully support thread local storage?

Yes

> (sidenote; if our thread
> local store code will use TLS then be-secure-openssl.c will be challenging to
> read =)).

Yes, let's rename it to SSL to avoid this. ;-)




Commits

  1. libpq: threadsafety for SSL certificate callback