Re: Serverside SNI support in libpq - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Serverside SNI support in libpq
Date
Msg-id DC2A4BB6-9D9D-4752-8296-6AE1321E8048@yesql.se
Whole thread Raw
In response to Re: Serverside SNI support in libpq  (Jacob Champion <jacob.champion@enterprisedb.com>)
Responses Re: Serverside SNI support in libpq
Re: Serverside SNI support in libpq
List pgsql-hackers
> On 18 Mar 2026, at 14:01, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>
> On Wed, Mar 18, 2026 at 5:19 AM Daniel Gustafsson <daniel@yesql.se> wrote:
>> longfin has so far reported a test failure which I am looking into.
>
> I took a quick look at culicidae and I think that's just due to the
> use of EXEC_BACKEND. Rather than $windows_os the SKIP logic should
> probably use something like 001_server's $exec_backend.

That's a bit embarrassing, I spent some time investigating passphrase reloading
under EXEC_BACKEND as part of this patchset..

The longfin issue is a bit more odd, I can reproduce it on macOS with OpenSSL
1.1.1 but nowhere else.  Rather than reporting an SSL error for aborted
handshake it reports a SYSCALL error.  Using SYSCALL error for when the server
close the connection abruptly is documented, but not really this case where it
does so with no error codes at all (which given OpenSSL documentation doesn't
really say much..).  The change in the attached diff does fix it for me but I'm
a bit hesitant to apply something like that, I would be more inclined to the
change the expected output in the test.  What are your thoughts?

--
Daniel Gustafsson


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Unicode update and some tooling improvements
Next
From: Andres Freund
Date:
Subject: Re: Read-only connection mode for AI workflows.