Re: backtrace_on_internal_error - Mailing list pgsql-hackers

From Tom Lane
Subject Re: backtrace_on_internal_error
Date
Msg-id 1266459.1701958930@sss.pgh.pa.us
Whole thread Raw
In response to Re: backtrace_on_internal_error  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: backtrace_on_internal_error
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Configure problem when cross-compiling PostgreSQL 16.1
Next
From: Matthias van de Meent
Date:
Subject: Re: initdb caching during tests