On Fri, Dec 13, 2019 at 7:26 AM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 2019-12-04 22:34, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > >> It'd be bad if the addition of backtraces for SEGV/BUS suddenly made it > >> harder to attach a debugger and getting useful results. > > > > Yeah. TBH, I'm not sure I want this, at least not in debug builds. > > I understand that the SEGV/BUS thing can be a bit scary. We can skip it. > > Are people interested in backtraces on abort()? That was asked for in > an earlier thread.
I mean, I think backtraces are great, and we should have more of them. It's possible that trying to do it in certain cases will cause problems, but we could back off those cases as we find them, or maybe try to work around them using sigaltstack(), or maybe back it off in debug builds. It would make life a lot easier for me if I never had to explain to a customer (1) how to install gdb or (2) that they needed to get $BOSS to approve installation of development tools on production systems. I would hate to see us shy away from improvements that might reduce the need for such conversations on the theory that bad stuff *might* happen. In my experience, the importance of having a stack trace in the log is greatest for a segmentation fault, because otherwise you have no indication whatsoever of where the problem happened. Having the query text has been a boon, but it's still not a lot to go on unless the same query crashes every time. In other situations, like a PANIC, Assertion failure, or (and this is a big one) non-descriptive error message (cache look failed for thingy %u) a backtrace is sometimes really helpful as well. You don't *always* need it, but you *often* need it. It is absolutely important that we don't break debuggability in the service of getting more stack traces. At the same time, there are a lot more PostgreSQL users out there than there are PostgreSQL developers, and a lot of those people are running non-cassert, non-debug builds. Being able to get debugging information from failures that happen on those installations that enables us to fix things without having to go through a time-consuming process of guesswork and attempted reproduction is really valuable. A stack trace can turn a lengthy nightmare into a quick fix. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company