On Thu, Jul 19, 2018 at 12:20:53PM -0700, Andres Freund wrote: > On 2018-07-19 11:57:25 +0300, Heikki Linnakangas wrote: > > 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.
I mean, only calling async-signal-safe functions from signal handlers is a critical POSIX requirement, and exit(3) is NOT async-signal-safe. > > 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? Is ereport() async-signal-safe? No. It could be, but it uses stdio to write to stderr/console, and stdio is not async-signal-safe. Nico --