Re: Internal error codes triggered by tests - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: Internal error codes triggered by tests
Date
Msg-id 3f1bef8d-1335-1214-5f84-581287708451@gmail.com
Whole thread Raw
In response to Re: Internal error codes triggered by tests  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Internal error codes triggered by tests
List pgsql-hackers
Hello Daniel and Michael,

12.07.2024 23:41, Daniel Gustafsson wrote:
>> On 10 Jul 2024, at 06:42, Michael Paquier <michael@paquier.xyz> wrote:
> The rest mentioned upthread seems either not worth the effort or are likely to
> be bugs warranting proper investigation.
>

I've filed a bug report about the "WITH RECURSIVE" anomaly: [1], but what
I wanted to understand when presenting different error kinds is what
definition XX000 errors could have in principle?

It seems to me that we can't define them as indicators of unexpected (from
the server's POV) conditions, similar to assertion failures (but produced
with no asserts enabled), which should be and mostly get fixed.

If the next thing to do is to get backtrace_on_internal_error back and
that GUC is mainly intended for developers, then maybe having clean (or
containing expected backtraces only) regression test logs is a final goal
and we should stop here. But if it's expected that that GUC could be
helpful for users to analyze such errors in production and thus pay extra
attention to them, maybe having XX000 status for presumably
unreachable conditions only is desirable...

[1] https://www.postgresql.org/message-id/18536-0a342ec07901203e%40postgresql.org

Best regards,
Alexander



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cannot find a working 64-bit integer type on Illumos
Next
From: Noah Misch
Date:
Subject: Re: race condition in pg_class