Re: Printing backtrace of postgres processes

On Wed, Feb 07, 2024 at 02:04:39PM +0530, Bharath Rupireddy wrote:
> Well, that 'ubuntu' is the default username there, I've changed it now
> and kept the output short.

I would keep it just at two or three lines, with a "For example, with
lines like":

> I've simplified the tests, now we don't need two separate output files
> for tests. Please see the attached v27 patch.

+ proname => 'pg_log_backtrace', provolatile => 'v', prorettype => 'bool',

Hmm. Would it be better to be in line with memory contexts logging
and use pg_log_backend_backtrace()? One thing I was wondering is that
there may be a good point in splitting the backtrace support into two
functions (backends and auxiliary processes) that could be split with
two execution ACLs across different roles.

+ PROCSIG_LOG_BACKTRACE, /* ask backend to log the current backtrace */

Incorrect order.

+-- Backtrace is not logged for auxiliary processes

Not sure there's a point in keeping that in the tests for now.

+ * XXX: It might be worth implementing it for auxiliary processes.

Same, I would remove that.

+static volatile sig_atomic_t backtrace_functions_loaded = false;

Hmm, so you need that because of the fact that it would be called in a
signal as backtrace(3) says:
"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".

True that it is not interesting to only log something when having a
CFI, this needs to be dynamic to get a precise state of things.
--
Michael