Re: Printing backtrace of postgres processes

At Thu, 10 Nov 2022 15:56:35 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Mon, Apr 18, 2022 at 9:10 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > The attached v21 patch has the changes for the same.
>
> Thanks for the patch. Here are some comments:
>
> 1. I think there's a fundamental problem with this patch, that is, it
> prints the backtrace when the interrupt is processed but not when
> interrupt is received. This way, the backends/aux processes will

Yeah, but the obstacle was backtrace(3) itself. Andres pointed [1]
that that may be doable with some care (and I agree to the opinion).
AFAIS no discussions followed and things have been to the current
shape since then.

[1] https://www.postgresql.org/message-id/20201201032649.aekv5b5dicvmovf4%40alap3.anarazel.de
| > Surely this is *utterly* unsafe. You can't do that sort of stuff in
| > a signal handler.
|
| That's of course true for the current implementation - but I don't think
| it's a fundamental constraint. With a bit of care backtrace() and
| backtrace_symbols() itself can be signal safe:

man 3 backtrace
> * backtrace() and backtrace_symbols_fd() don't call malloc() explic‐
> itly, but they are part of libgcc, which gets loaded dynamically
> when first used. Dynamic loading usually triggers a call to mal‐
> loc(3). If you need certain calls to these two functions to not
> allocate memory (in signal handlers, for example), you need to make
> sure libgcc is loaded beforehand.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center