Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket

On 2018-07-19 14:54:52 -0500, Nico Williams wrote:
> 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.

There's a few standard requirements that aren't particularly relevant in
practice (including some functions not being listed as signal
safe). Just arguing from that isn't really helpful. But there's plenty
hard evidence, including a few messages upthread!, of it being
practically problematic. Just looking at the reasoning at why exit (and
malloc) aren't signal safe however, makes it clear that this particular
restriction should be adhered to, however.

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

Im not sure what you're trying to tell me here? What you quoted doesn't
advocate doing anything with ereport()?

Greetings,

Andres Freund