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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, 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-02 16:48:12
Message-ID: zn5n6xqnkdyto7iviknl3q2gcy7m4w6ha4xi343rzcruoto3gj@l7tz4g2ongtv
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-11-02 16:48:22 Re: [PATCH] Periodically refresh database frozen IDs during autovacuum
Previous Message Jingtang Zhang 2026-11-02 16:43:00 Re: Stale hash entries when reusing an auxiliary resource owner