Re: backtrace_on_internal_error

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

In response to

Responses

Browse pgsql-hackers by date

  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