Re: Weird "null" errors during DROP TYPE (pg_upgrade)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Devrim Gündüz <devrim(at)gunduz(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Weird "null" errors during DROP TYPE (pg_upgrade)
Date: 2024-05-03 00:18:59
Message-ID: 2430404.1714695539@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim(at)gunduz(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-05-03 01:04:15 Re: allow changing autovacuum_max_workers without restarting
Previous Message Robert Haas 2024-05-03 00:11:48 Re: Support LIKE with nondeterministic collations