Re: Use of signal-unsafe functions from signal handlers
От
Tom Lane
Тема
Re: Use of signal-unsafe functions from signal handlers
Дата
Msg-id
1531973.1653401755@sss.pgh.pa.us
Ответ на
Re: Use of signal-unsafe functions from signal handlers (Julien Rouhaud)
Список
Дерево обсуждения
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
Дата: