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

Hi,

On 2026-08-26 10:26:58 -0400, Tom Lane wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> > Please take a look at the follow-up to [0]. I've prepared a patch to
> > assign error codes for errors reached by the following queries:
>
> I'm not on board with these proposed changes to [try_]relation_open.
> They're basically band-aids rather than fixes of the root problems.
> That is, if someone passes OID 0 to relation_open, that IS an internal
> bug; labeling it otherwise is a lie and does nothing to fix the real
> problem at the caller level.
>
> A lot of these other proposed changes have the same whiff of blaming
> the messenger rather than looking for the root cause.

+1.

This is triply true for stuff like test_pglz_decompress() - this isn't
something that should be translated or that we care about having a proper
error code assigned.

Most of these would make it *harder* to find unexpected scenarios, i.e. the
patch would make the situation strictly worse. It's useful to be able to
search production logs for internal errors. As-is the patch would break that.

Looking through them, the ones that look relatively clearly to be worth
turning into ereports seem to be:

- pg_get_shmem_allocations_numa() - there's really no reason for this to be an
elog(), it's obviously expected to be reached on a bunch of platforms / configurations
- transformColumnDefinition() - that's clearly reachable with plain DDL,
without representing a bug in an upper layer.

I'm a bit on the fence about the one get_range_io_data(). We could catch that
on a higher layer, but
a) that'd be duplicated code,
b) other errors, like not having send/receive are already handled in
get_range_io_data, with ereports()
c) for e.g. composites, we handle the same problem centrally, rather than have
checks in record_in() etc (the check is in lookup_rowtype_tupdesc_internal).

Looking at this reminds me of something orthogonal: Isn't it pretty weird that
we have a per-type cache, with lots of information about the types, but don't
have the in/out/send/recv cached in there, but do cache EQ/LT/.. etc?

Greetings,

Andres Freund