Re: libpq OpenSSL and multithreading - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: libpq OpenSSL and multithreading
Date
Msg-id F4DD42A0-6B5E-4349-A93C-F752DF1644BE@yesql.se
Whole thread Raw
In response to Re: libpq OpenSSL and multithreading  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
> On 2 Jul 2025, at 13:44, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 27.06.25 19:24, Daniel Gustafsson wrote:
>> The OpenSSL code in libpq have two issues for multithreading: the verify_cb
>> callback use a global variable to pass back error detail state and there is one
>> use of strerror().
>
> Slightly misleading title: This is actually about the *backend* libpq code.

Point taken, proposed commitmessage has been updated.

>> The attached fixes both, with no functional change, in order to pave the way
>> for multithreading:
>>   * Rather than using a global variable the callback use a new member in the
>>   Port struct for passing the string, and the Port struct is in turn passed as
>>   private data in the SSL object
>
> Couldn't this also be done by making that global variable thread-local? But getting rid of it is even nicer.

It absolutely could, and I briefly considered this approach, but I prefer
getting rid of it altogether.

>>   * The strerror call is replaced with a strerror_r call using the already
>>   existing errorbuffer
>
> This one was already discussed some time ago at
<https://www.postgresql.org/message-id/flat/daa87d79-c044-46c4-8458-8d77241ed7b0%40eisentraut.org>:
>
> > But the bigger issue is that the use of a static buffer makes
> > this not thread-safe, so having it use strerror_r to fill that
> > buffer is just putting lipstick on a pig.
>
> It looks like your patch doesn't address that?

Doh, of course.  The attached v2 takes a stab at moving from using a static
buffer to a palloced buffer with the caller being responsible for freeing.  In
paths which lead to proc_exit we can omit freeing.

--
Daniel Gustafsson


Attachment

pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION
Next
From: Fujii Masao
Date:
Subject: Re: A assert failure when initdb with track_commit_timestamp=on