Hi, On 2023-11-27 16:16:25 -0600, Nathan Bossart wrote: > On Wed, Nov 22, 2023 at 02:59:45PM -0800, Andres Freund wrote: > > Hm. I wonder if this indicates an issue. Do the preceding changes perhaps > > make it more likely that a child process of the startup process could hang > > around for longer, because the signal we're delivering doesn't terminate > > child > > processes, because we'd just reset the signal handler? I think it's fine > > for > > the startup process, because we ask the startup process to shut down with > > SIGTERM, which defaults to exiting. > > > > But we do have a few processes that we do ask to shut down with other > > signals, wich do not trigger an exit by default, e.g. Checkpointer, > > archiver, > > walsender are asked to shut down using SIGUSR2 IIRC. The only one where > > that > > could be an issue is archiver, I guess? > > This did cross my mind. AFAICT most default handlers already trigger an > exit (including SIGUSR2), and for the ones that don't, we'd just end up in > the same situation as if the signal arrived a moment later after the child > process has installed its own handlers. And postmaster doesn't send > certain signals (e.g., SIGHUP) to the whole process group, so we don't have > the opposite problem where things like reloading configuration files > terminates these child processes. > > So, I didn't notice any potential issues. Did you have anything else in > mind?
No, I just was wondering about issues in this area. I couldn't immediately think of a concrete scenario, so I thought I'd mention it here. Greetings, Andres Freund
