Re: backtrace_on_internal_error - Mailing list pgsql-hackers

From Tom Lane
Subject Re: backtrace_on_internal_error
Date
Msg-id 98860.1703003366@sss.pgh.pa.us
Whole thread Raw
In response to Re: backtrace_on_internal_error  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: backtrace_on_internal_error
Re: backtrace_on_internal_error
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> The last change we made in this area that, at least for me, massively
> improved debuggability was the change to log the current query string
> when a backend crashes. That's such a huge help; I can't imagine going
> back to the old way where you had basically no idea what made things
> go boom. I think doing something like this can have a similarly
> positive impact. It is going to take some work - from us and from
> extension authors - to tidy things up so that it doesn't produce a
> bunch of unwanted output, but the payoff will be the ability to
> actually find and fix the bugs instead of just saying to a customer
> "hey, sucks that you hit a bug, let us know if you find a reproducer."

IMO, we aren't really going to get a massive payoff from this with
the current backtrace output; it's just not detailed enough.  It's
better than nothing certainly, but to really move the goalposts
we'd need something approaching gdb's "bt full" output.  I wonder
if it'd be sane to try to auto-invoke gdb.  That's just blue sky
for now, though.  In the meantime, I agree with the proposal as it
stands (that is, auto-backtrace on any XX000 error).  We'll soon find
out whether it's useless, or needs more detail to be really helpful,
or is just right as it is.  Once we have some practical experience
with it, we can course-correct as needed.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ishaan Adarsh
Date:
Subject: Re: [DOC] Introducing Quick Start Guide to PL/pgSQL and PL/Python Documentation
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Add --check option to pgindent