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
> 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