Re: Printing backtrace of postgres processes

On Mon, Nov 15, 2021 at 11:37 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, Nov 15, 2021 at 10:34 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> >
> > Thanks for the comments, the attached v12 patch has the changes for the same.
>
> I have reviewed this patch and have some comments on v12-0001,
>
> 1.
> + This feature is not supported for the postmaster, logger, checkpointer,
> + walwriter, background writer or statistics collector process. This
>
>
> Comment says it is not supported for postmaster, logger, checkpointer
> etc, but I just tried and it is working for checkpointer and walwriter
> processes, can you explain in comments why do we not want to support
> for these processes? or the comment is old and now we are supporting
> for some of these processes.
>
>
> 2.
> postgres[64154]=# select pg_print_backtrace(64136);
> WARNING: 01000: PID 64136 is not a PostgreSQL server process
> LOCATION: pg_print_backtrace, signalfuncs.c:335
> pg_print_backtrace
> --------------------
> f
>
>
> For postmaster I am getting this WARNING "PID 64136 is not a
> PostgreSQL server process", even if we don't want to support this
> process I don't think this message is good.
>
>
>
> 3.
> I was looking into the patch, I tried to print the backtrace using GDB
> as well as using this function, I have complied in debug mode, I can
> see the backtrace printed
> by GDB is more detailed than printed by this API, I understand we can
> find out the function name from address, but can't we print the
> detailed call stack with all function names at least when debug
> symbols are available?
>
> Using GDB
>
> #0 0x00007fa26c527e93 in __epoll_wait_nocancel () from
> #1 0x0000000000947a61 in WaitEventSetWaitBlock (set=0x2
> #2 0x00000000009478f9 in WaitEventSetWait (set=0x2f0111
> #3 0x00000000007a6cef in secure_read (port=0x2f26800, p
> #4 0x00000000007b0bd6 in pq_recvbuf () at pqcomm.c:957
> #5 0x00000000007b0c86 in pq_getbyte () at pqcomm.c:1000
> #6 0x0000000000978c13 in SocketBackend (inBuf=0x7ffea99
> #7 0x0000000000978e37 in ReadCommand (inBuf=0x7ffea9937
> #8 0x000000000097dca5 in PostgresMain (dbname=0x2f2ef40
> ....
>
> Using pg_print_backtrace
> postgres: dilipkumar postgres [local]
> SELECT(set_backtrace+0x38) [0xb118ff]
> postgres: dilipkumar postgres [local]
> SELECT(ProcessPrintBacktraceInterrupt+0x5b) [0x94fe42]
> postgres: dilipkumar postgres [local]
> SELECT(ProcessInterrupts+0x7d9) [0x97cb2a]
> postgres: dilipkumar postgres [local] SELECT() [0x78143c]
> postgres: dilipkumar postgres [local] SELECT() [0x736731]
> postgres: dilipkumar postgres [local] SELECT() [0x738f5f]
> postgres: dilipkumar postgres [local]
> SELECT(standard_ExecutorRun+0x1d6) [0x736d94]
> postgres: dilipkumar postgres [local] SELECT(ExecutorRun+0x55)
> [0x736bbc]
> postgres: dilipkumar postgres [local] SELECT() [0x97ff0c]
> postgres: dilipkumar postgres [local] SELECT(PortalRun+0x268) [0x97fbbf]
> postgres: dilipkumar postgres [local] SELECT() [0x9798dc]
> postgres: dilipkumar postgres [local]
> SELECT(PostgresMain+0x6ca) [0x97dda7]

I did not find any API's with such an implementation. We have used
backtrace and backtrace_symbols to print the address. Same thing is
used to add error backtrace and print backtrace for assert failure,
see errbacktrace and ExceptionalCondition. I felt this is ok.

> 4.
> +WARNING: backtrace generation is not supported by this installation
> + pg_print_backtrace
> +--------------------
> + f
>
> Should we give some hints on how to enable that?

Modified to include a hint message.
The Attached v13 patch has the fix for it.

Regards,
Vignesh