At Thu, 10 Nov 2022 15:56:35 +0530, Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote in > On Mon, Apr 18, 2022 at 9:10 AM vignesh C <vignes...@gmail.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
