Re: Weird "null" errors during DROP TYPE (pg_upgrade) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Weird "null" errors during DROP TYPE (pg_upgrade)
Date
Msg-id 2430404.1714695539@sss.pgh.pa.us
Whole thread Raw
In response to Weird "null" errors during DROP TYPE (pg_upgrade)  (Devrim Gündüz <devrim@gunduz.org>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Support LIKE with nondeterministic collations
Next
From: Nathan Bossart
Date:
Subject: Re: allow changing autovacuum_max_workers without restarting