Re: Use of signal-unsafe functions from signal handlers

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Use of signal-unsafe functions from signal handlers
Дата
в 14:15:55
Msg-id
1531973.1653401755@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Use of signal-unsafe functions from signal handlers Mats Kindahl <mats@timescale.com>
Re: Use of signal-unsafe functions from signal handlers Julien Rouhaud <rjuju123@gmail.com>
Re: Use of signal-unsafe functions from signal handlers Mats Kindahl <mats@timescale.com>
Re: Use of signal-unsafe functions from signal handlers Julien Rouhaud <rjuju123@gmail.com>
Re: Use of signal-unsafe functions from signal handlers Tom Lane <tgl@sss.pgh.pa.us>
Re: Use of signal-unsafe functions from signal handlers Michael Paquier <michael@paquier.xyz>
Re: Use of signal-unsafe functions from signal handlers Tom Lane <tgl@sss.pgh.pa.us>
Re: Use of signal-unsafe functions from signal handlers Andres Freund <andres@anarazel.de>
Julien Rouhaud  writes:
> Yes, but it's using ereport with FATAL level, so if it's the top level message
> the ErrorContext should be in initial state or have been reset previously, and
> if it's not then the escape hatch will reset the context.  So in any case there
> will be a guarantee to have at least 8kB available in that context, that any
> palloc will be able to use to format the message.

ereport() itself is just the tip of the iceberg; even if it's safe
(which I concur it isn't), there's also the atexit/on_proc_exit
functions that are likely to be called during shutdown.  So yeah,
this coding is not too safe.  I'm not sure that getting rid of it
would be a net win though, as we'd replace it-might-crash hazards
with it-might-never-exit hazards, from bgworkers that neglect to
respond to ShutdownRequestPending.

			regards, tom lane


В списке pgsql-bugs по дате отправления
От: Julien Rouhaud
Дата:
От: PG Bug reporting form
Дата:
FAQ