Re: PATCH: backtraces for error messages - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: PATCH: backtraces for error messages
Date
Msg-id 20180621.200909.165892238.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: PATCH: backtraces for error messages  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: PATCH: backtraces for error messages
List pgsql-hackers
Hello, I basically like this.

At Thu, 21 Jun 2018 12:35:10 +0800, Craig Ringer <craig@2ndquadrant.com> wrote in
<CAMsr+YGFMVnFLRSf09GGgjUyxv3C0ytep9ftM8N2X1kLM-SkKw@mail.gmail.com>
> This is what the stacks look like btw
> 
> 
> [2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] DEBUG:  00000:
> find_in_dynamic_libpath: trying
> "/home/craig/pg/10/lib/postgresql/pglogical.so"
> [2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] LOCATION:
> find_in_dynamic_libpath, dfmgr.c:639
> [2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] STACK:
>     FRAME    0: find_in_dynamic_libpath +628
>     FRAME    1: expand_dynamic_library_name +205
>     FRAME    2: load_external_function +38
>     FRAME    3: LookupBackgroundWorkerFunction +197
>     FRAME    4: StartBackgroundWorker +549
>     FRAME    5: do_start_bgworker +466
>     FRAME    6: maybe_start_bgworkers +382
>     FRAME    7: reaper +895
>     FRAME    8: funlockfile +80
>     FRAME    9: __select +23
>     FRAME   10: ServerLoop +394
>     FRAME   11: PostmasterMain +4499
> 
> 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.
> 
> It also goes to show there are plenty of places you might want to get a
> stack where you don't have an internal errcode or panic. I don't think that
> idea will fly.

I think this for assertion failure is no problem but I'm not sure
for other cases. We could set proper context description or other
additional information in error messages before just dumping a
trace for known cases.

Since PG9.5 RPMs are complied with --enable-dtrace so we could
use system tap to insert the stack-trace stuff. Additional
built-in probe in error reporting system or assertions would make
this pluggable.

However, system tap doesn't work for me but I'm not sure how it
is broken. (stap version is 3.2/0.170 and uname -r shows
3.10.0-862)

$ sudo stap -e  'probe process(".../bin/postgres").mark("transaction__start"){}'
...
LOG:  autovacuum launcher process (PID 10592) was terminated by signal 4: Illegal instruction


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Possible bug in logical replication.
Next
From: Pavan Deolasee
Date:
Subject: Re: PATCH: backtraces for error messages