Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket
От | Nico Williams |
---|---|
Тема | Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket |
Дата | |
Msg-id | 20180808215154.GZ5695@localhost обсуждение исходный текст |
Ответ на | Re: [HACKERS] possible self-deadlock window after badProcessStartupPacket (Nico Williams <nico@cryptonector.com>) |
Список | pgsql-hackers |
On Wed, Aug 08, 2018 at 11:47:34AM -0500, Nico Williams wrote: > Yes. Would that snprintf() and vsnprintf() were async-signal-safe -- > they can be, and some implementations probably are, but they aren't > required to be, then making ereport() safe would be easier. So, I took a look at glibc's implementation for giggles. It uses malloc() (and free()) only in three cases: a) when printing floating point numbers with very large/small exponents, b) when formatting long wide strings into multi-byte strings, c) when formatting specifiers have width asterisks. Assuming locales are not lazily loaded, I think that's probably all the reasonable cases where vsnprintf() could call async-signal-unsafe functions or do async-signal-unsafe things. Considering that PostgreSQL already has async-signal-unsafe signal handlers, might as well assume that vsnprintf() is async-signal-safe and just format strings into alloca()'ed buffers or even into fixed-sized automatic char arrays, and be done. Perhaps when a global volatile sig_atomic_t is set denoting we're handling a signal, then use vsnprintf() with a fixed-sized automatic buffer, otherwise malloc() one. Nico --
В списке pgsql-hackers по дате отправления: