On Tue, May 24, 2022 at 02:10:36PM +0200, Mats Kindahl wrote:
> On Tue, May 24, 2022 at 12:14 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > As mentioned in the topmost comment of elog.c, there's an escape hatch for
> > out of memory situations, to make sure that a small enough message can be
> > displayed without trying to allocate memory. But this is only for ERROR or
> > higher levels. Using an ereport(LOG, ...) level in a sigterm handler
> > indeed
> > isn't safe.
> >
>
> Yes, and we have already fixed this in the TimescaleDB code, so this is not
> an issue for us (https://github.com/timescale/timescaledb/pull/4323). (We
> actually replace the bgworker_die with just die as signal handler.)
>
> However, bgworker_die()---which is part of PostgreSQL and is the default
> signal handler for background workers---is using ereport() and I think this
> should be a problem for all error levels since the problem is in the usage
> of the formatting function to format the error message, not where you write
> it. This would mean that any existing background workers would have a
> window for triggering this issue on shutdown.
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.