Re: backtrace_on_internal_error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: backtrace_on_internal_error
Дата
Msg-id 1439034.1702047909@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: backtrace_on_internal_error  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: backtrace_on_internal_error
Список pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> Here is a patch to play with.

Didn't read the patch yet, but ...

> One possible question for discussion is whether the default for this 
> should be off, on, or possibly something like on-in-assert-builds. 
> (Personally, I'm happy to turn it on myself at run time, but everyone 
> has different workflows.)

... there was already opinion upthread that this should be on by
default, which I agree with.  You shouldn't be hitting cases like
this commonly (if so, they're bugs to fix or the errcode should be
rethought), and the failure might be pretty hard to reproduce.

I'm not really sold that we even need YA GUC, for that matter.
How about committing the behavior without a GUC, and then
back-filling one if we get pushback?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: GUC names in messages
Следующее
От: Robert Haas
Дата:
Сообщение: Re: UBSan pointer overflow in xlogreader.c