Re: We shouldn't signal process groups with SIGQUIT

Hi,

On 2023-02-28 13:45:41 +0900, Michael Paquier wrote:
> On Tue, Feb 14, 2023 at 12:47:12PM -0800, Andres Freund wrote:
> > Just naively hacking this behaviour change into the current code, would yield
> > sending SIGQUIT to postgres, and then SIGTERM to the whole process
> > group. Which seems like a reasonable order? quickdie() should _exit()
> > immediately in the signal handler, so we shouldn't get to processing the
> > SIGTERM. Even if both signals are "reacted to" at the same time, possibly
> > with SIGTERM being processed first, the SIGQUIT handler should be executed
> > long before the next CFI().
>
> I have been poking a bit at that, and did a change as simple as this
> one in signal_child():
> #ifdef HAVE_SETSID
> + if (signal == SIGQUIT)
> + signal = SIGTERM;

FWIW, one thing that kept me from actually proposing a patch is that I thought
it might be useful to write a test for this, but that I didn't yet have the
cycles to look into that.

> From what I can see, SIGTERM is actually received by the backends
> before SIGQUIT, and I can also see that the backends have enough room
> to process CFIs in some cases, especially short queries, even before
> reaching quickdie() and its exit(). So the window between SIGTERM and
> SIGQUIT is not as long as one would think.

What do you mean with the last ssentence? Why would one think that the window
between them is long? Do you mean that it's not as short?

Greetings,

Andres Freund