Honestly, I don’t know what to do with bgworker_die(). At the moment it
produces ereport(FATAL) with async-unsafe proc_exit_prepare() and exit()
underhood. I can see three solutions:
1. Leave the code as is. Then SIGTERM can produce deadlocks in bgworker's
signal handler. The locked process
> 28 авг. 2021 г., в 07:05, Andres Freund написал(а):
>
> However, we have a
> bandaid that deals with possible hangs, by SIGKILLing when processes don't
> shut down (at that point things have already gone quite south, so that's not
> an issue).
Thanks for the explanation. I can see that
Hi,
On 2021-08-27 23:51:27 +0300, Denis Smirnov wrote:
> > 26 авг. 2021 г., в 23:39, Tom Lane написал(а):
> >
> > (BTW, I think it's pretty silly to imagine that adding backtrace()
> > calls inside ereport is making things any more dangerous. ereport
> > has pretty much always carried a
> 26 авг. 2021 г., в 23:39, Tom Lane написал(а):
>
> (BTW, I think it's pretty silly to imagine that adding backtrace()
> calls inside ereport is making things any more dangerous. ereport
> has pretty much always carried a likelihood of calling malloc(),
> for example.)
I have taken a look
Robert Haas writes:
> That is a great question. I think bgworker_die() is extremely
> dangerous and ought to be removed. I can't see how that can ever be
> safe.
Agreed, it looks pretty dangerous from here. The equivalent (and
far better battle-tested) signal handlers in postgres.c are a lot
> inside bgworker_die() and FloatExceptionHandler() signal handlers. I am
> confused with this fact - both backtrace functions are async-unsafe:
> backtrace_symbols() - always, backtrace() - only for the first call due to
> dlopen. I wonder why does PostgreSQL use async-unsafe functions in sig
> inside errfinish() that is wrapped by ereport() macros. ereport() is invoked
>> inside bgworker_die() and FloatExceptionHandler() signal handlers. I am
>> confused with this fact - both backtrace functions are async-unsafe:
>> backtrace_symbols() - always, backtrace() -
oked
> inside bgworker_die() and FloatExceptionHandler() signal handlers. I am
> confused with this fact - both backtrace functions are async-unsafe:
> backtrace_symbols() - always, backtrace() - only for the first call due to
> dlopen. I wonder why does PostgreSQL use async-unsafe funct
with this fact - both backtrace functions are async-unsafe:
backtrace_symbols() - always, backtrace() - only for the first call due to
dlopen. I wonder why does PostgreSQL use async-unsafe functions in signal
handlers?
Best regards,
Denis Smirnov | Developer
s...@arenadata.io
Arenadata | Godovikova 9
