Re: Internal error codes triggered by tests
От | Alexander Lakhin |
---|---|
Тема | Re: Internal error codes triggered by tests |
Дата | |
Msg-id | 3f1bef8d-1335-1214-5f84-581287708451@gmail.com обсуждение исходный текст |
Ответ на | Re: Internal error codes triggered by tests (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: Internal error codes triggered by tests
|
Список | 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 по дате отправления: