Re: common signal handler protection

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