Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Printing backtrace of postgres processes
Date
Msg-id 1778088.1606026308@sss.pgh.pa.us
Whole thread Raw
In response to Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
Responses Re: Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
Re: Printing backtrace of postgres processes  (Craig Ringer <craig.ringer@enterprisedb.com>)
Re: Printing backtrace of postgres processes  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
vignesh C <vignesh21@gmail.com> writes:
> The idea here is to implement & expose pg_print_callstack function,
> internally what this function does is, the connected backend will send
> SIGUSR1 signal by setting PMSIGNAL_BACKTRACE_EMIT to the postmaster
> process. Postmaster process will send a SIGUSR1 signal to the process
> by setting PROCSIG_BACKTRACE_PRINT if the process has access to
> ProcSignal. As syslogger process & Stats process don't have access to
> ProcSignal, multiplexing with SIGUSR1 is not possible for these
> processes, hence SIGUSR2 signal will be sent for these processes. Once
> the process receives this signal it will log the backtrace of the
> process.

Surely this is *utterly* unsafe.  You can't do that sort of stuff in
a signal handler.

It might be all right to set a flag that would cause the next
CHECK_FOR_INTERRUPTS to print a backtrace, but I'm not sure
how useful that really is.

The proposed postmaster.c addition seems quite useless, as there
is exactly one stack trace it could ever log.

I would like to see some discussion of the security implications
of such a feature, as well.  ("There aren't any" is the wrong
answer.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Printing backtrace of postgres processes
Next
From: James Hilliard
Date:
Subject: [PATCH 1/1] Initial mach based shared memory support.