Am Freitag, 29. Januar 2021, 18:55:42 CET schrieb Tom Lane:
> GMX LINREG <linreg@gmx.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
Hello,
after "REINDEX TABLE pg_depend" the problem still persists.
So I agree "the evidence is long gone";
I will perfrom a pg_dump/psql combo to restore and upgrade the database to
main version 13. Since version 9.6 we have had a lot of pg_upgrades.
Thank you very much.
Best regards from Germany
Thomas Steffen
