Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket

On 19/07/18 03:26, Asim R P wrote:
> On Thu, Jun 22, 2017 at 10:50 AM, Andres Freund <andres@anarazel.de> wrote:
>>
>> Or, probably more robust: Simply _exit(2) without further ado, and rely
>> on postmaster to output an appropriate error message. Arguably it's not
>> actually useful to see hundreds of "WARNING: terminating connection because of
>> crash of another server process" messages in the log anyway.
>>
> 
> To support using _exit(2) in *quickdie() handlers, I would like to
> share another stack trace indicating self-deadlock.  In this case, WAL
> writer process got SIGQUIT while it was already handling a SIGQUIT,
> leading to self-deadlock.

Ugh. Yeah, in wal_quickdie, and other aux process *_quickdie() handlers, 
I agree we should just _exit(2). All we want to do is to exit the 
process immediately.

bgworker_quickdie() makes some effort to block SIGQUIT during the exit() 
processing, but that doesn't solve the whole problem. The process 
could've been in the middle of a malloc/free when the signal arrived, 
for example. exit() is simply not safe to call from a signal handler.

The regular backend's quickdie() function is more tricky. It should also 
call _exit(2) rather than exit(2). But it also tries to ereport a 
WARNING, and that is quite useful. ereport() is generally not safe in a 
signal handler. There is some protection for specific failures: see 
socket_putmessage(), for example, which has a mechanism to prevent a 
message from being sent to the client in the middle of another message. 
But at the end of the day, ereport() is complicated enough that it will 
surely do a lot of unsafe things.

I don't have any great ideas on how to make the ereport(WARNING) safer, 
but I agree we should at least change all the exit(2) calls in quickdie 
handlers to _exit(2).

BTW, if postmaster is still alive, it will send a SIGKILL to any child 
process that doesn't terminate in 5 seconds. So a deadlock in SIGQUIT 
handler isn't that bad. Some other nasty things could happen, however; 
all bets are off if you call unsafe functions from a signal handler.

- Heikki