Hi, On 2023-02-02 14:39:19 -0800, Nathan Bossart wrote: > Actually, this still doesn't really explain why we need to exit immediately > in the SIGTERM handler for restore_command. We already have handling for > when the command indicates it exited due to SIGTERM, so it should be no > problem if the command receives it before the startup process. And > HandleStartupProcInterrupts() should exit at an appropriate time after the > startup process receives SIGTERM.
> My guess was that this is meant to allow breaking out of the system() call, > but I don't understand why that's important here. Maybe we could just > remove this exit-in-SIGTERM-handler business... I don't think you can, at least not easily. For one, we have no guarantee that the child process got a signal at all - we don't have a hard dependency on setsid(). And even if we have setsid(), there's no guarantee that the executed process reacts to SIGTERM and that the child didn't create its own process group (and thus isn't reached by the signal to the process group, sent in signal_child()). Greetings, Andres Freund
