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 can
> 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 child
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 likelih
> 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 th
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
mor
On Wed, Aug 25, 2021 at 10:22 AM Denis Smirnov wrote:
> I am going to refactor Greenplum backtraces for error messages and want to
> make it more compatible with PostgreSQL code. Backtraces in PostgreSQL were
> introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original
> discussion
As far as I understand, the main problem with backtrace_symbols() is the
internal malloc() call. Backend can lock forever if malloc() was interrupted by
a signal and then was evaluated again in a signal handler.
At the moment Greenplum uses "addr2line -s -e» (on Linux) and "atos -o" (on
macOS)
> 25 авг. 2021 г., в 19:22, Denis Smirnov написал(а):
>
> I am going to refactor Greenplum backtraces for error messages and want to
> make it more compatible with PostgreSQL code. Backtraces in PostgreSQL were
> introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original
> disc
