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:29:34
Message-ID: 2815190.1611941374@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message GMX LINREG 2021-01-29 17:38:18 Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
Previous Message GMX LINREG 2021-01-29 16:40:46 Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed