Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
В списке pgsql-hackers по дате отправления:
| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера