Re: backtrace_on_internal_error
| От | Robert Haas |
|---|---|
| Тема | Re: backtrace_on_internal_error |
| Дата | |
| Msg-id | CA+TgmoagWVtAM9_E7LV+q48LthoND-F6=GRaPQ=jqe+0OiHL7g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: backtrace_on_internal_error (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Tue, Dec 19, 2023 at 11:29 AM Tom Lane <tgl@sss.pgh.pa.us> 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. That all seems fair to me. I'm more optimistic than you are about getting something useful out of the current backtrace output, but (1) I could be wrong, (2) I'd still like to have something better, and (3) improving the backtrace output is a separate project from including backtraces more frequently. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: