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

Hello Michael,

05.07.2024 03:57, Michael Paquier wrote:
> On Thu, Jul 04, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote:
>> Could you please share your thoughts regarding other error cases, which is
>> not triggered by existing tests, but still can be easily reached by users?
>>
>> For example:
>> SELECT satisfies_hash_partition(1, 1, 0, 0);
>>
>> ERROR:  XX000: could not open relation with OID 1
>> LOCATION:  relation_open, relation.c:61
>>
>> or:
>> CREATE TABLE t (b bytea);
>> INSERT INTO t SELECT ''::bytea;
>> CREATE INDEX brinidx ON t USING brin
>>   (b bytea_bloom_ops(n_distinct_per_range = -1.0));
>>
>> ERROR:  XX000: the bloom filter is too large (44629 > 8144)
>> LOCATION:  bloom_init, brin_bloom.c:344
>>
>> Should such cases be corrected too?
> This is a case-by-case.  satisfies_hash_partition() is undocumented,
> so doing nothing is fine by me.  The second one, though is something
> taht can be triggered with rather normal DDL sequences.  That's more
> annoying.

Thank you for the answer!

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

--
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

--
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

--
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...)

--
CREATE EXTENSION ltree;
SELECT '1' ::ltree @ (repeat('!', 100)) ::ltxtquery;

ERROR:  XX000: stack too short
LOCATION:  makepol, ltxtquery_io.c:252

--
There is also a couple of dubious ereport(DEBUG1,
(errcode(ERRCODE_INTERNAL_ERROR), ...) calls like:
         /*
          * User-defined picksplit failed to create an actual split, ie it put
          * everything on the same side.  Complain but cope.
          */
         ereport(DEBUG1,
                 (errcode(ERRCODE_INTERNAL_ERROR),
                  errmsg("picksplit method for column %d of index \"%s\" failed",
                         attno + 1, RelationGetRelationName(r)),

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.

Best regards,
Alexander