Re: errbacktrace

On Tue, Jun 25, 2019 at 4:08 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> New thread continuing from
> <
> https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2e73@2ndquadrant.com
> >.
>
> Here is a extended version of Álvaro's patch that adds an errbacktrace()
> function. You can do two things with this:
>
> - Manually attach it to an ereport() call site that you want to debug.
>
> - Set a configuration parameter like backtrace_function = 'int8in' to
> debug ereport()/elog() calls in a specific function.
>

Thank You. This is very helpful. Surprised is missing for so long time. We
have printing backtrace in Greenplum and its extremely helpful during
development and production.

There was also mention of settings that would automatically produce
> backtraces for PANICs etc. Those could surely be added if there is
> enough interest.
>

In Greenplum, we have backtrace enabled for PANICs, SEGV/BUS/ILL and
internal ERRORs, proves very helpful.

For the implementation, I support both backtrace() provided by the OS as
> well as using libunwind. The former seems to be supported by a number
> of platforms, including glibc, macOS, and FreeBSD, so maybe we don't
> need the libunwind suport. I haven't found any difference in quality in
> the backtraces between the two approaches, but surely that is highly
> dependent on the exact configuration.
>

We have implemented it using backtrace(). Also, using addr2line() (or atos
for mac) can convert addresses to file and line numbers before printing if
available, to take it a step further.