Postgres Pro
Downloads
Home   >   mailing lists

Re: errbacktrace - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: errbacktrace
Date
Msg-id CAFj8pRDG3tCD5k+r2D5Y++fc7aR3LQUQF-3EA6XJhkGtJgXyzA@mail.gmail.com
Whole thread Raw
In response to Re: errbacktrace  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: errbacktrace  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Tree view
Hi

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);


If I understand well, backtrace is displayed only when edata->funcname is same like backtrace_function GUC. Isn't it too strong limit?

For example, I want to see backtrace for all PANIC level errors on production, and I would not to limit the source function?

Regards

Pavel



 
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




pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Do not check unlogged indexes on standby
Next
From: Jeevan Chalke
Date:
Subject: Re: block-level incremental backup