Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
Date
Msg-id 2815190.1611941374@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed  (GMX LINREG <linreg@gmx.net>)
Responses Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed  (GMX LINREG <linreg@gmx.net>)
List pgsql-bugs
Looking at this more closely, it seems like there must be something broken
about the plperlu extension in the source database.  We see

pg_restore: erstelle EXTENSION »plperlu«
pg_restore: erstelle COMMENT »EXTENSION "plperlu"«
pg_restore: erstelle PROCEDURAL LANGUAGE »plperlu«
pg_restore: in Phase PROCESSING TOC:
pg_restore: in Inhaltsverzeichniseintrag 2151; 2612 16427 PROCEDURAL LANGUAGE plperlu postgres
pg_restore: Fehler: could not execute query: FEHLER:  Sprache »plperlu« existiert nicht
Die Anweisung war: CREATE OR REPLACE PROCEDURAL LANGUAGE "plperlu";

but a binary-upgrade dump should have dumped the plperlu support functions
before the procedural language object.  And the CREATE PROCEDURAL LANGUAGE
command should have included explicit HANDLER etc clauses.  Both things
could be explained by supposing that pg_dump didn't see the support
functions as part of the extension, but why not?

It might be interesting to check the results of "\dx+ plperlu" in the
source database.

            regards, tom lane



pgsql-bugs by date:

Previous
From: GMX LINREG
Date:
Subject: Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
Next
From: GMX LINREG
Date:
Subject: Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed