| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, 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-08-12 11:19:41 |
| Message-ID: | CAFj8pRDG3tCD5k+r2D5Y++fc7aR3LQUQF-3EA6XJhkGtJgXyzA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
>
>
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeevan Chalke | 2019-08-12 11:57:29 | Re: block-level incremental backup |
| Previous Message | Andrey Borodin | 2019-08-12 09:58:24 | Do not check unlogged indexes on standby |