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

Поиск
Список
Период
Сортировка
От Nico Williams
Тема Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Дата
Msg-id 20180719200727.GL9712@localhost
обсуждение исходный текст
Ответ на Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Nico Williams
Дата:
Сообщение: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket