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

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Subject: Re: Internal error codes triggered by regression tests and user queries, take 2
Date: 2026-11-12 10:29:20
Message-ID: CALdSSPi3x7673tu=wMeN=r1pKbzPj5gGc8u+DAqs0ZRpMnY3oQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2 Nov 2026 at 22:44, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>
> 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

Another case

begin;
create type tt AS (a int, b int);
prepare x as SELECT (i, 1)::tt FROM generate_series(1,1) i;
rollback ;
execute x;
--- ERROR: cache lookup failed for type 16487

found by looking into
https://git.postgresql.org/cgit/postgresql.git/commit/?id=0b0f5c5af11b868c15ae2f80010e351f04a6b2e5

--
Best regards,
Kirill Reshke

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ilia Evdokimov 2026-11-12 10:36:14 Re: Memoize: stale entry pointer after cache_store_tuple()
Previous Message Tomas Vondra 2026-11-12 10:28:51 Re: reconsider_full_join_clause fails to consider if COALESCE() arguments are NULL-preserving