Horton

Re: Printing backtrace of postgres processes

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: vignesh C <vignesh21@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-16T20:21:31Z
Lists: pgsql-hackers 
vignesh C <vignesh21@gmail.com> writes:
> On Sat, Jan 16, 2021 at 1:40 AM Andres Freund <andres@anarazel.de> wrote:
>> Why is a full signal needed? Seems the procsignal infrastructure should
>> suffice?

> Most of the processes have access to ProcSignal, for these processes
> printing of callstack signal was handled by using ProcSignal. Pgstat
> process & syslogger process do not have access to ProcSignal,
> multiplexing with SIGUSR1 is not possible for these processes. So I
> handled the printing of callstack for pgstat process & syslogger using
> the SIGUSR2 signal.

I'd argue that backtraces for those processes aren't really essential,
and indeed that trying to make the syslogger report its own backtrace
is damn dangerous.

(Personally, I think this whole patch fails the safety-vs-usefulness
tradeoff, but I expect I'll get shouted down.)

			regards, tom lane

Commits

  1. Perform apply of large transactions by parallel workers.

  2. Enhance pg_log_backend_memory_contexts() for auxiliary processes.

  3. Allow GRANT on pg_log_backend_memory_contexts().

  4. Move Perl test modules to a better namespace

  5. Unify PostgresNode's new() and get_new_node() methods

  6. Add backtrace support for error reporting