On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh <gurjeet@singh.im> wrote:
> There's an symmetry, almost a diametric opposition, between how SSL
> initialization error is treated when it occurs during server startup,
> versus when the error occurs during a reload/SIGHUP. During startup an
> error in SSL initialization leads to FATAL, whereas during a SIGHUP
> it's merely a LOG message.
>
> I found this difference in treatment of SSL initialization errors
> quite bothersome, and there is no ready explanation for this. Either a
> properly initialized SSL stack is important for server operation, or
> it is not. What do we gain by letting the server operate normally
> after a reload that failed to initialize SSL stack. Conversely, why do
> we kill the server during startup on SSL initialization error, when
> it's okay to operate normally after a reload that is unable to
> initialize SSL.
I think you're overreacting to a behavior that isn't really very surprising.
If we don't initialize SSL the first time, we don't have a working SSL
stack. If we didn't choose to die at that point, we'd be starting up a
server that could not accept any SSL connections. I don't think users
would like that.
If we don't *reinitialize* it, we *do* have a working SSL stack. We
haven't been able to load the updated configuration, but we still have
the old one. We could fall over and die anyway, but I don't think
users would like that either. People don't expect 'pg_ctl reload' to
kill off a working server, even if the new configuration is bad.
So I don't really know what behavior, other than what is actually
implemented, would be reasonable.
--
Robert Haas
EDB: http://www.enterprisedb.com