From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: backtrace_on_internal_error |
Date: | 2023-12-07 14:22:10 |
Message-ID: | 1266459.1701958930@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2023-12-07 14:27:10 | Re: initdb caching during tests |
Previous Message | Tom Lane | 2023-12-07 14:18:13 | Re: Configure problem when cross-compiling PostgreSQL 16.1 |