Re: PATCH: backtraces for error messages

Поиск
Список
Период
Сортировка
От Korry Douglas
Тема Re: PATCH: backtraces for error messages
Дата
Msg-id CAPqDkTPiodDhfHBit_+mnGZLSc5SqeJOVOwGu4sJrc9Ku1RxJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: backtraces for error messages  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: PATCH: backtraces for error messages  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
A few misc comments:

In general, +1.

It might be nice to move the stack trace code into a separate function (not static to elog.c) - I have often found it useful to attach backtraces to objects so I can debug complex allocation/deallocation problems.  

The major expense in capturing a stack trace is in the symbolization of the stack addresses, not the stack walk itself.  You typically want to symbolize the addresses at the time you generate the trace, but that's not always the case.  For example, if you want to record the stack trace of every call to AllocSetAlloc() (and attach the trace to the AllocChunk) performance gets unbearable if you symbolize every trace.  So a flag that specifies whether to symbolize would be nice too. 

If you don't symbolize, you need a way to capture the address range of each dynamically loaded shared object (so that you can later symbolize using something like addr2line).  

(The above suggestions relate to server debugging, not application debugging).

End of wish list...

     -- Korry

On Fri, Jun 22, 2018 at 3:07 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 22 June 2018 at 08:48, Andres Freund <andres@anarazel.de> wrote:
On 2018-06-22 08:24:45 +0800, Craig Ringer wrote:
> On Thu., 21 Jun. 2018, 19:26 Pavan Deolasee, <pavan.deolasee@gmail.com>
> wrote:
>
> >
> >
> > On Thu, Jun 21, 2018 at 11:02 AM, Michael Paquier <michael@paquier.xyz>
> > wrote:
> >
> >> On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote:
> >> > I wrote it because I got sick of Assert(false) debugging, and I was
> >> chasing
> >> > down some "ERROR:  08P01: insufficient data left in message" errors.
> >> Then I
> >> > got kind of caught up in it... you know how it is.
> >>
> >> Yes, I know that feeling!  I have been using as well the Assert(false)
> >> and the upgrade-to-PANIC tricks a couple of times, so being able to get
> >> more easily backtraces would be really nice.
> >>
> >>
> > Sometime back I'd suggested an idea to be able to dynamically manage log
> > levels for elog messages [1].
> >
>
>
> Huge +1 from me on being able to selectively manage logging on a
> module/subsystem, file, or line level.
>
> I don't think I saw the post.
>
> Such a thing would obviously make built in backtrace support much more
> useful.

I strongly suggest keeping these as separate as possible. Either is
useful without the other, and both are nontrivial. Tackling them
together imo makes it much more likely to get nowhere.


Totally agree, and it's why I raised this as its own thing.

Thanks.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCH] Include application_name in "connection authorized" logmessage
Следующее
От: Rui DeSousa
Дата:
Сообщение: Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query