Re: Rotate SSL certificates on reload (SIGHUP) without restart

Hi Tatsuo,

Thanks for double-checking! Please feel free to go ahead and write the
regression tests if you're up for it. I'd really appreciate the help.

Regards,
Bob

On Tue, Mar 31, 2026 at 11:48 AM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

> > Hi Tatsuo,
> >
> > I believe no additional changes are needed for healthcheck and streaming
> > replication check.
> >
> > My patch focuses on the frontend-accept path, where SSL_ServerSide_init()
> > maintains a process-wide cached SSL_frontend_context reused across
> incoming
> > TLS handshakes, and therefore must be explicitly refreshed on reload.
> >
> > In contrast, the health check (src/main/health_check.c) and the SR check
> > worker (src/streaming_replication/pool_worker_child.c) establish outgoing
> > connections to PostgreSQL backends via pool_ssl_negotiate_clientserver().
> > This invokes init_ssl_ctx() for each new connection, creating a fresh
> > SSL_CTX and reading SSL-related settings (ssl_cert, ssl_key, ssl_ca_cert,
> > etc.) directly from pool_config at connection time. There is no
> long-lived
> > SSL context to refresh in these processes.
> >
> > Given that the SSL configuration parameters are now marked as
> CFGCXT_RELOAD
> > in src/config/pool_config_variables.c, a SIGHUP causes both processes to
> > reload pool_config via their respective reload_config() functions. As a
> > result, subsequent outgoing backend connections will naturally pick up
> the
> > updated certificate settings.
>
> Thank you for the explanation. Yes, health check and SR check worker
> establish connection to backend every time they need. I should have
> remembered that.
>
> I am going to write a regression test for this feature unless you are
> willing to work on it.
>
> Regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>