On Fri, Dec 13, 2019 at 7:26 AM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 2019-12-04 22:34, Tom Lane wrote:
> > Andres Freund <andres@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