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

From Nico Williams
Subject Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Date
Msg-id 20180808164733.GY5695@localhost
Whole thread Raw
In response to Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
List pgsql-hackers
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
-- 


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: REINDEX and shared catalogs
Next
From: Tom Lane
Date:
Subject: POC for a function trust mechanism