Re: backtrace_on_internal_error
От | Tom Lane |
---|---|
Тема | Re: backtrace_on_internal_error |
Дата | |
Msg-id | 956072.1701806902@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: backtrace_on_internal_error (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Список | pgsql-hackers |
Matthias van de Meent <boekewurm+postgres@gmail.com> writes: > On Tue, 5 Dec 2023 at 19:30, Robert Haas <robertmhaas@gmail.com> wrote: >>> I think we should consider unconditionally emitting a backtrace when >>> an elog() is hit, instead of requiring a GUC. >> Perhaps this should be a GUC that defaults to LOG or ERROR. > I can't speak for Nathan, but my reason would be that I'm not in the > habit to attach a debugger to my program to keep track of state > progression, but instead use elog() during patch development. I'm not > super stoked for getting my developmental elog(LOG)-s spammed with > stack traces, so I'd want to set this at least to ERROR, while in > production LOG could be fine. Yeah, I would not be happy either with elog(LOG) suddenly getting 10x more verbose. I think it might be okay to unconditionally do this when elevel >= ERROR, though. (At the same time, I don't have a problem with the idea of a GUC controlling the minimum elevel to cause the report. Other people might have other use-cases than I do.) regards, tom lane
В списке pgsql-hackers по дате отправления: