Hi, On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > On 19/07/18 03:26, Asim R P wrote: > > On Thu, Jun 22, 2017 at 10:50 AM, Andres Freund <and...@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.
Indeed. > 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. Yea. I really don't understand why we have't been able to agree on this for *years* now. > 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. Is that actually true? Clients like libpq create the same error message (which has its own issues, because it'll sometimes mis-interpret things). The message doesn't actually have useful content, no? Greetings, Andres Freund