Обсуждение: Weird "null" errors during DROP TYPE (pg_upgrade)

Hi,

pg_ugprade from v15 to v16 failed in an environment. Often we get a
reasonable message, but this time it was a bit weird. First, error
message:

=====================================================================================
pg_restore: creating TYPE "foobar._packagestoptemp"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 2418; 1247 20529 TYPE _packagestoptemp developer
pg_restore: error: could not execute query: ERROR:  type "_packagestoptemp" does not exist
HINT:  Create the type as a shell type, then create its I/O functions, then do a full CREATE TYPE.
Command was:
-- For binary upgrade, must preserve pg_type oid
SELECT pg_catalog.binary_upgrade_set_next_pg_type_oid('20529'::pg_catalog.oid);

CREATE TYPE "foobar"."_packagestoptemp" (
    INTERNALLENGTH = variable,
    INPUT = "array_in",
    OUTPUT = "array_out",
    RECEIVE = "array_recv",
    SEND = "array_send",
    ANALYZE = "array_typanalyze",
    SUBSCRIPT = "array_subscript_handler",
    ELEMENT = ???,
    CATEGORY = 'A',
    ALIGNMENT = double,
    STORAGE = extended
);
=====================================================================================

We noticed that this data type was actually not used, so decided to drop it:

===================
DROP TYPE "foobar"."_packagestoptemp";
ERROR:  cannot drop (null) because (null) requires it
HINT:  You can drop (null) instead.

===================

What do these "null" mean here? Any hints?,

Thanks!

Regards,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
> pg_ugprade from v15 to v16 failed in an environment. Often we get a
> reasonable message, but this time it was a bit weird. First, error
> message:

It seems like the source database must have been in quite a corrupt
state already --- here we have the array type _packagestoptemp, but
there's apparently no underlying type packagestoptemp, because
format_type seems to have failed for it:

>     ELEMENT = ???,

Can you show a way to get into this state without manual catalog
hacking?

> ===================
> DROP TYPE "foobar"."_packagestoptemp";
> ERROR:  cannot drop (null) because (null) requires it
> HINT:  You can drop (null) instead.
> ===================

> What do these "null" mean here? Any hints?,

Probably some catalog lookup function failed and returned NULL,
and then sprintf decided to print "(null)" instead of dumping
core (cf 3779ac62d).  This is more evidence in favor of catalog
corruption, but it doesn't tell us exactly what kind.

Maybe reindexing pg_type would improve matters?

            regards, tom lane