Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket

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
--