Re: Internal error codes triggered by tests

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

In response to

Responses

Browse pgsql-hackers by date

  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