Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: GMX LINREG <linreg(at)gmx(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
Date: 2021-01-29 17:55:42
Message-ID: 2816651.1611942942@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

GMX LINREG <linreg(at)gmx(dot)net> writes:
> output from source database:
> botdb=# \dx+ plperlu
> Objekte in Erweiterung »plperlu«
> Objektbeschreibung
> --------------------
> language plperlu

Yeah, that's definitely broken: it should look like

\dx+ plperlu
Objects in extension "plperlu"
Object description
-------------------------------------------
function plperlu_call_handler()
function plperlu_inline_handler(internal)
function plperlu_validator(oid)
language plperlu
(4 rows)

Offhand I think that completely explains pg_dump's failure: it relies on
the dependency-membership entries to decide that it ought to dump the
language support functions, so if they're not there, this is what you get.

It's possible that the entries *are* there but they're not being found due
to index corruption. You could try "REINDEX TABLE pg_depend" and see if
the \dx+ output changes. I don't have a lot of hope for that though.

The next easiest fix would be to see if you have any plperlu functions
to worry about, and if not, just drop the busted extension.

If you do have some such functions, the best bet might be to dump
them separately, go ahead and DROP CASCADE the busted extension,
then upgrade; and restore the plperlu functions separately afterwards.

It'd be kind of interesting to figure out why those pg_depend entries
are missing, but I suppose the evidence is long gone :-(

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-01-29 22:26:17 Re: Postgress 13.x: wrong result for delete with subquery
Previous Message Lucas Valardao 2021-01-29 17:44:45 Re: BUG #16844: Relation mapping file "global/pg_filenode.map" contains invalid data