Re: We shouldn't signal process groups with SIGQUIT

Hi,

On 2023-03-02 12:29:28 +1300, Thomas Munro wrote:
> In theory you could straighten this out by asking what else is pending
> so that we imposed our own priority, if that were a problem, but there
> is something I don't understand: you said we could handle SIGTERM and
> then make it all the way to CFI() (= non-signal handler code) before
> handling a SIGQUIT that was sent first. Huh... what am I missing? I
> thought the only risk was handlers running in the opposite of send
> order because they 'overlapped', not non-handler code being allowed to
> run in between.

I see ProcessInterrupts() being called too - but it's independent of the
changes we discuss here. The reason for it is the CFI() at the end of
errfinish().

Note that ProcessInterrupts() immediately returns, due to the
HOLD_INTERRUPTS() at the start of quickdie().

FWIW, here's the strace output of a backend, enriched with a few debug
write()s.

epoll_wait(5, 0x55b25764fd70, 1, -1) = -1 EINTR (Interrupted system call)
--- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=759211, si_uid=1000} ---
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=759211, si_uid=1000} ---
write(2, "start die\n", 10) = 10
kill(759218, SIGURG) = 0
write(2, "end die\n", 8) = 8
rt_sigreturn({mask=[QUIT URG]}) = 0
write(2, "start quickdie\n", 15) = 15
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP ABRT BUS FPE SEGV CONT SYS RTMIN RT_1], NULL, 8) = 0
sendto(10, "N\0\0\0tSWARNING\0VWARNING\0C57P01\0Mt"..., 117, 0, NULL, 0) = 117
write(2, "ProcessInterrupts\n", 18) = 18
write(2, "ProcessInterrupts held off\n", 27) = 27
write(2, "end quickdie\n", 13) = 13
exit_group(2) = ?
+++ exited with 2 +++

We do way too many non-signal safe things in quickdie(). But I'm not sure what
the alternative is, given we probably do want to send something to the client.

Greetings,

Andres Freund