Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Date
Msg-id 20180719201339.52m22e5u7jnj3hlh@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket  (Nico Williams <nico@cryptonector.com>)
Responses Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket