Re: PATCH: backtraces for error messages

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: PATCH: backtraces for error messages
Дата
Msg-id 20180620155828.2mwdbz6uyjsxwmmr@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: PATCH: backtraces for error messages  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: PATCH: backtraces for error messages  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2018-06-20 11:20:49 -0400, Alvaro Herrera wrote:
> > I recently needed a way to get backtraces from errors in a convenient,
> > non-interactive and indescriminate way. The attached patch is the result.
> > It teaches Pg to use libunwind to self-backtrace in elog/ereport.
> > 
> > Anyone think this is useful/interesting/worth pursuing?

Generally interesting, yes.


> I think we sorely need some mechanism to optionally get backtraces in
> error messages.  I think having backtraces in all messages is definitely
> not a good thing, but requiring an explicit marker (such as in my patch)
> means the code has to be recompiled, which is not a solution in
> production systems.  I kind lean towards your approach, but it has to be
> something that's easily enabled/disabled at runtime.

> I have no idea how expensive backtrace() and libunwind are, but I doubt
> we want to pay the cost for every message before we know that error
> requires the backtrace to be collected.  Something like PGC_USERSET
>   server_min_backtraces=PANIC 
> might be a possible interface.

Yes, most definitely. We can't do this everywhere. It's quite expensive
to collect / build them.  So I think we'd probably need another guc that
controls when the information is collected, perhaps defaulting to PANIC.

Greetings,

Andres Freund


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: ORDER/GROUP BY expression not found in targetlist