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.

Please let me know what you think.

Best regards,
Bob