On 2017-02-02 12:18:22 -0800, Jimmy Yih wrote:
> In the above pull request, Heikki also mentions that a similar scenario can
> happen during palloc() as well... which is similar to what we saw in
> Greenplum a couple years back for a deadlock in a malloc() call where we
> responded by changing exit() to _exit() in quickdie as a fix. That could
> possibly be applicable to latest Postgres as well.
Isn't the quickdie() issue that we palloc/malloc in the first place,
rather than the exit call? There's some risk for exit() too, but we
reset our own atexit handlers before exiting, so the risk seems fairly
small.
In my opinion the fix here would be to do it right and never emit error
messages from signal handlers via elog.c - we've progressed a lot
towards the goal and do a lot less in signal handlers these days - but
quickdie() is one glaring exception to that. I think a reasonable fix
here would be to use write() of a statically allocated message, rather
then elog proper, and not to send the message to the client. Libpq, and
I presume other clients, synthethize a message upon unexpected socket
closure anyway, and it's completely unclear whether we can send a
message anyway.
Greetings,
Andres Freund