Re: backtrace_on_internal_error
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-12-30T11:11:59Z
Lists: pgsql-hackers
On 19.12.23 17:29, Tom Lane wrote: > 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. Based on this, I have committed my original patch.
Commits
-
Add GUC backtrace_on_internal_error
- a740b213d4b4 17.0 landed
-
Fix variable name and comment
- 541e8f14a185 17.0 landed
-
Be more wary about OpenSSL not setting errno on error.
- ebbd499d4b55 16.2 landed
- 87b46ad90491 13.14 landed
- 551d4b28e445 15.6 landed
- 271d24f31ddd 12.18 landed
- 0a5c46a7a488 17.0 landed
- 07ce2432682d 14.11 landed