Re: We shouldn't signal process groups with SIGQUIT

Hi,

On 2023-02-14 15:38:24 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > ISTM that signal_child() should downgrade SIGQUIT to SIGTERM when sending to
> > the process group. That way we'd maintain the current behaviour for postgres
> > itself, but stop core-dumping archive/restore scripts (as well as other
> > subprocesses that e.g. trusted PLs might create).
>
> Yeah, I had been thinking along the same lines. One issue
> is that that means the backend itself will get SIGQUIT and SIGTERM
> in close succession. We need to make sure that that won't cause
> problems. It might be prudent to think about what order to send
> the two signals in.

I hope we already deal with that reasonably well - I think it's not uncommon
for that to happen, regardless of this change.

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().

Not really related: I do wonder how often we end up self deadlocking in
quickdie(), due to the ereport() not beeing reentrant. We'll "fix" it soon
after, due to postmasters SIGKILL. Perhaps we should turn on
send_abort_for_kill on CI?

Greetings,

Andres Freund