Re: errbacktrace

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: errbacktrace
Date: 2019-07-08 16:28:51
Message-ID: 20190708162851.GA11054@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Jul-08, Dmitry Dolgov wrote:

> > On Sat, Jun 29, 2019 at 7:41 AM Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> wrote:
> >
> > This is certainly a very useful thing. Sadly, it doesn't seem to compile when
> > trying to use libunwind.
>
> Yeah, the same for me. To make it works I've restricted libunwind to local
> unwinding only:
>
> #ifdef USE_LIBUNWIND
> #define UNW_LOCAL_ONLY
> #include <libunwind.h>
> #endif

Ah, yes. unwind's manpage says:

Normally, libunwind supports both local and remote unwinding (the latter will
be explained in the next section). However, if you tell libunwind that your
program only needs local unwinding, then a special implementation can be
selected which may run much faster than the generic implementation which
supports both kinds of unwinding. To select this optimized version, simply
define the macro UNW_LOCAL_ONLY before including the headerfile <libunwind.h>.

so I agree with unconditionally defining that symbol.

Nitpicking dept: I think in these tests:

+ if (!edata->backtrace &&
+ edata->funcname &&
+ backtrace_function[0] &&
+ strcmp(backtrace_function, edata->funcname) == 0)
+ set_backtrace(edata, 2);

we should test for backtrace_function[0] before edata->funcname, since
it seems more likely to be unset.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-08 16:37:54 Re: Switching PL/Python to Python 3 by default in PostgreSQL 12
Previous Message Tom Lane 2019-07-08 16:25:24 Re: Switching PL/Python to Python 3 by default in PostgreSQL 12