Re: backtrace_on_internal_error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: backtrace_on_internal_error
Дата
Msg-id 1266459.1701958930@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: backtrace_on_internal_error  (Peter Eisentraut <peter@eisentraut.org>)
Ответы Re: backtrace_on_internal_error  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
> Something else to note:  I wrote the above code to check the error code; 
> it doesn't check whether the original code write elog() or ereport(). 
> There are some internal errors that are written as ereport() now. 
> Others might be changed from time to time; until now there would have 
> been no external effect from this.  I think it would be weird to 
> introduce a difference between these forms now.

Yeah, that was bothering me too.  IIRC, elog is already documented
as being *exactly equivalent* to ereport with a minimal set of
options.  I don't think we should break that equivalence.  So I
agree with driving this off the stated-or-imputed errcode rather
than which function is called.

> Do people want a way to distinguish ERROR/FATAL/PANIC?
> Or do people want a way to enable backtraces for elog(LOG)?

Personally I don't see a need for either.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Configure problem when cross-compiling PostgreSQL 16.1
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: initdb caching during tests