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 20180719200727.GL9712@localhost
Whole thread Raw
In response to Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jul 19, 2018 at 04:04:01PM -0400, Tom Lane wrote:
> Nico Williams <nico@cryptonector.com> writes:
> > What I'd do is have a volatile sig_atomic_t in_signal_handler_context
> > variable to indicate that we're dying, and then when that is non-zero,
> > ereport() and friends could use all-async-signal-safe codepaths.
> 
> I eagerly await your patch with an async-safe implementation of ereport...

Once my ALWAYS DEFERRED patch is done, sure :)

Also, see my other post just now where I propose a thread-based
mechanism for making quickdie() async-signal-safe.  Basically, there
would be a pipe and a thread that only blocks in read(2) on that pipe,
and quickdie() would write to the pipe the relevant details, then that
thread would call ereport() and then exit(3).  This would be much much
simpler to implement than making ereport() async-signal-safe.

Nico
-- 


pgsql-hackers by date:

Previous
From: Nico Williams
Date:
Subject: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket