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