From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Internal error codes triggered by tests |
Date: | 2024-07-14 16:00:00 |
Message-ID: | 3f1bef8d-1335-1214-5f84-581287708451@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Daniel and Michael,
12.07.2024 23:41, Daniel Gustafsson wrote:
>> On 10 Jul 2024, at 06:42, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-07-14 17:48:00 | Re: race condition in pg_class |
Previous Message | Tom Lane | 2024-07-14 14:51:54 | Re: Cannot find a working 64-bit integer type on Illumos |