From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Printing backtrace of postgres processes |
Date: | 2020-11-22 06:25:08 |
Message-ID: | 1778088.1606026308@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
vignesh C <vignesh21(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | James Hilliard | 2020-11-22 08:19:30 | [PATCH 1/1] Initial mach based shared memory support. |
Previous Message | vignesh C | 2020-11-22 03:06:25 | Printing backtrace of postgres processes |