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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
