Hi. At Mon, 25 Jun 2018 09:32:36 +0800, Craig Ringer <cr...@2ndquadrant.com> wrote in <camsr+ygbw9tgkrgxyihvemzmjqx_2t8d17te7t5-0gmdw7s...@mail.gmail.com> > On 21 June 2018 at 19:09, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp > > wrote: > > I think this for assertion failure is no problem but I'm not sure > > for other cases. > > > I think it's pretty strongly desirable for PANIC.
Ah, I forgot about that. I agree to that. The cost to collect the information is not a problem on PANIC. However still I don't think stack trace is valuable on all PANIC messages. I can accept the guc to control it but it is preferable that this works fine without such an extra setup. > > We could set proper context description or other > > additional information in error messages before just dumping a > > trace for known cases. > > > > Yeah. The trouble there is that there are a _lot_ of places to touch for > such things, and inevitably the one you really want to see will be > something that didn't get suitably annotated. Agreed, it is the reality. Instaed, can't we make a new error classes PANIC_STACKDUMP and ERROR_STACKDUMP to explicitly restrict stack dump for elog()? Or elog_stackdump() and elog() is also fine for me. Using it is easier than proper annotating. It would be perfect if we could invent an automated way but I don't think it is realistic. > > 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. > > > > I don't bother with SystemTAP anymore; perf does the job for most purposes. > > You can use --enable-dtrace SDTs with Perf fine. I wrote it up for Pg at > https://wiki.postgresql.org/wiki/Profiling_with_perf#PostgreSQL_pre-defined_tracepoint_events > . > > Dynamic tracepoints are also very useful. > > Both require debuginfo, but so does outputting of symbolic stacks per my > patch. Mmm. If I understand you correctly, I mean that perf doesn't dump a backtrace on a probe point but trace points are usable to take a symbolic backtrace. (I'm sorry that I cannot provide an example since stap doesn't work in my box..) If your intention is to take back traces without any setting (I think it is preferable), it should be restricted to the required points. It can be achieved by the additional error classes or substitute error output functions. As just an idea but can't we use an definition file on that LOCATION of error messages that needs to dump a backtrace are listed? That list is usually empty and should be very short if any. The LOCATION information is easily obtained from a verbose error message itself if once shown but a bit hard to find otherwise.. > (That reminds me, I need to chat with Devrim about creating a longer lived > debuginfo + old versions rpms repo for Pg its self, if not the accessory > bits and pieces. I'm so constantly frustrated by not being able to get > needed debuginfo packages to investigate some core or running system > problem because they've been purged from the PGDG yum repo as soon as a new > version comes out.) We in our department take care to preserve them for ourselves for the necessity of supporting older systems. I sometimes feel that It is very helpful if they were available on the official site. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
