Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 19/07/18 03:26, Asim R P wrote:
> On Thu, Jun 22, 2017 at 10:50 AM, Andres Freund <andres(at)anarazel(dot)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