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

From Daniel Gustafsson
Subject Re: Serverside SNI support in libpq
Date
Msg-id D015F102-C458-42F6-8787-E3D9F2B17A69@yesql.se
Whole thread
In response to Re: Serverside SNI support in libpq  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: Serverside SNI support in libpq
Re: Serverside SNI support in libpq
List pgsql-hackers
> On 22 Sep 2026, at 12:19, Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> + /*
> + * If the initialization failed, and the ssl_sni setting was changed, we
> + * need to revert ssl_sni back to the previous setting to match the SSL
> + * configuration left in place.  Log a WARNING to alert the user.
> + */
> + if (SSL_hosts->sni_enabled != ssl_sni)
> + {
>
> Won't this cause a different crash without a null check for SSL_hosts?

Yeah, I overlooked that case and missed subjecting to LLM review as CoPilot
immediately complained about that as well.  Should've had coffee before
emailing.

> Also, this seems to be a partial revert only affecting new sessions,
> still leaving existing sessions with an incorrect value, that won't be
> confusing?

In the v3 the ssl_sni value isn't reverted at all, which albeit confusing is in
line with how we treat (and document) SSL configuration so I think thats the
better option.  Flipping it in existing sessions would require a lot more
infrastructure for little gain.

--
Daniel Gustafsson


Attachment

pgsql-hackers by date:

Previous
From: Manu
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
Next
From: Devrim Gündüz
Date:
Subject: [PATCH] Misleading error message for REPACK USING INDEX on shared catalogs