Re: libpq OpenSSL and multithreading

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq OpenSSL and multithreading
Date: 2025-10-22 08:59:35
Message-ID: 12577264-4DBD-45E7-8243-81AD4CC2CDDC@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 1 Sep 2025, at 07:27, Peter Eisentraut <peter(at)eisentraut(dot)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 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? (sidenote; if our thread
local store code will use TLS then be-secure-openssl.c will be challenging to
read =)).

I've left out this portion in the attached and only left the callback private
data change.

--
Daniel Gustafsson

Attachment Content-Type Size
v3-0001-libpq-Make-SSL-certificate-callback-in-backend-th.patch application/octet-stream 3.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-10-22 09:02:01 Re: Client-only Meson Build From Sources
Previous Message Chao Li 2025-10-22 08:57:37 Re: Why cannot alter a column's type when it's used by a generated column