Re: Internal error codes triggered by regression tests and user queries, take 2

On Mon, 2 Nov 2026 at 21:48, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,

Hi!

> On 2026-11-01 12:09:37 -0500, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > On 2026-11-01 17:13:26 +0500, Kirill Reshke wrote:
> > >> Filtering my report with this rule, I think we need to take care of 4-7, 11, 13
> >
> > > We're quite busy, being flooded with bug reports and ginormous patches. Why
> > > are we trying to find even more work by searching for inconsequential stuff
> > > like this? I really don't get it. Like, you wrote a fuzzer to search for
> > > these. WHY?
> >
> > The reason was mentioned at the top of the thread: some people monitor
> > their logs for XX000 errors.
>
> I agree that we should fix XX000s that can appear in logs in realistic
> ways.

Okay. The thing started with my thread [0] where I have reported an
error which I encountered myself (we have a set of private patches
about locales).

> But:
>
> > I agree that we can't afford to spend a lot of effort on this, but fixing
> > easily-reached cases seems like a reasonable thing to do, IMO.
>
> I guess I just don't think stuff that needs to be found via a fuzzer and
> requires e.g. hand-making outdated recv input for ltree, or calling deprecated
> trigger functions (autoinc) outside of triggers are that.

OK, I can agree all error are not-likely-sql-reachable, expect case 13
from my report, which is a real server bug in catcache.

> Greetings,
>
> Andres Freund

[0] https://www.postgresql.org/message-id/CALdSSPhHy0HeptBdEhaetg%2BabhG_qjRgMb0BB38%2B7JezC4jnzA%40mail.gmail.com

--
Best regards,
Kirill Reshke