On Wed, Aug 08, 2018 at 07:19:34PM +0300, Heikki Linnakangas wrote: > On 20/07/18 18:03, Andres Freund wrote: > >It's much less the exit() that's unsafe, than the callbacks themselves, > >right? Perhaps just restate that we wouldn't want to trigger atexit > >processing due to signal safety? > > Well, in principle exit() is unsafe too, although you're right that in > practice it's more likely the callbacks that would cause trouble. I reworded > the comment to put more emphasis on the callbacks.
It's unsafe because it will: - flush stdio buffers - call atexit handlers (which might, e.g., free()) - who knows what else It's easy enough to decide to exit() or _exit(). If you tell can't which to call from lexical context, then use a global volatile sig_atomic_t variable to indicate that we're exiting from a signal handler and check that variable in the quickdie() functions. > So, with this commit, the various SIGQUIT quickdie handlers are in a better > shape. The regular backend's quickdie() handler still calls ereport(), which > is not safe, but it's a step in the right direction. And we haven't > addressed the original complaint, which was actually about startup_die(), > not quickdie(). Yes. Would that snprintf() and vsnprintf() were async-signal-safe -- they can be, and some implementations probably are, but they aren't required to be, then making ereport() safe would be easier. Nico --
