On Thu, May 26, 2022 at 1:05 AM Gurjeet Singh <gurj...@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
