Re: Internal error codes triggered by tests - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Internal error codes triggered by tests
Date
Msg-id Zo4ROR9mgy8bowMo@paquier.xyz
Whole thread Raw
In response to Re: Internal error codes triggered by tests  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: Internal error codes triggered by tests
List pgsql-hackers
On Mon, Jul 08, 2024 at 12:00:00PM +0300, Alexander Lakhin wrote:
> Let me show you other error types for discussion/classification:
> SELECT pg_describe_object(1::regclass, 0, 0);
>
> ERROR:  XX000: unsupported object class: 1
> LOCATION:  getObjectDescription, objectaddress.c:4016
> or
> SELECT pg_identify_object_as_address('1'::regclass, 1, 1);
>
> ERROR:  XX000: unsupported object class: 1
> LOCATION:  getObjectTypeDescription, objectaddress.c:4597

These ones are old enough, indeed.  Knowing that they usually come
down to be used with scans of pg_shdepend and pg_depend to get some
information about the objects involved, I've never come down to see if
these were really worth tackling.  The cases of dropped/undefined
case is much more interesting, because we may give in input object IDs
that have been dropped concurrently.  Class IDs are constants fixed in
time.

> --
> SELECT format('BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> SET TRANSACTION SNAPSHOT ''%s''', repeat('-', 1000))
> \gexec
> ERROR:  XX000: could not open file "pg_snapshots/-----...---" for reading: File name too long
> LOCATION:  ImportSnapshot, snapmgr.c:1428

This one is fun.  errcode_for_file_access() does not know about
ENAMETOOLONG, as an effect of the errno returned by AllocateFile().
Perhaps it should map to ERRCODE_NAME_TOO_LONG?

> CREATE OPERATOR === (leftarg = int4, rightarg = int4, procedure = int4eq,
>   commutator = ===, hashes);
>
> CREATE TABLE t1 (a int);
> ANALYZE t1;
> CREATE TABLE t2 (a int);
>
> SELECT * FROM t1, t2 WHERE t1.a === t2.a;
>
> ERROR:  XX000: could not find hash function for hash operator 16385
> LOCATION:  ExecHashTableCreate, nodeHash.c:560

Hehe.  You are telling that this operator supports a hash join, but
nope.  I am not really convinced that this is worth worrying.


> --
> WITH RECURSIVE oq(x) AS (
>     WITH iq as (SELECT * FROM oq)
>     SELECT * FROM iq
>     UNION
>     SELECT * from iq
> )
> SELECT * FROM oq;
>
> ERROR:  XX000: missing recursive reference
> LOCATION:  checkWellFormedRecursion, parse_cte.c:896
> (commented as "should not happen", but still...)

Hmm.  This one feels like a bug, indeed.

> --
> CREATE EXTENSION ltree;
> SELECT '1' ::ltree @ (repeat('!', 100)) ::ltxtquery;
>
> ERROR:  XX000: stack too short
> LOCATION:  makepol, ltxtquery_io.c:252

ltree has little maintenance, not sure that's worth worrying.

> I'm not mentioning errors, that require more analysis and maybe correcting
> the surrounding logic, not ERRCODE only.
>
> Maybe it makes sense to separate the discussion of such errors, which are
> not triggered by tests/not covered; I'm just not sure how to handle them
> efficiently.

The scope is too broad for some of them like the CTE case, so separate
threads to attract the correct review audience makes sense to me.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: array_in sub function ReadArrayDimensions error message
Next
From: Kartyshov Ivan
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed