From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, 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-16 01:32:01 |
Message-ID: | ZpXNkbaGUJns1K-N@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 14, 2024 at 07:00:00PM +0300, Alexander Lakhin wrote:
> 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?
Cool, thanks! I can see that Tom has already committed a fix.
I'm going to start a new thread for ERRCODE_NAME_TOO_LONG. It would
be confusing to solve the issue in the middle of this thread.
> 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...
Perhaps. Let's see where it leads if we have this discussion again.
Some internal errors cannot be avoided because some tests expect such
cases (failures with on-disk file manipulation is one).
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-07-16 01:37:39 | Re: Flush pgstats file during checkpoints |
Previous Message | David G. Johnston | 2024-07-16 01:28:54 | Re: Duplicate unique key values in inheritance tables |