Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
От | Tom Lane |
---|---|
Тема | Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed |
Дата | |
Msg-id | 2815190.1611941374@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed (GMX LINREG <linreg@gmx.net>) |
Ответы |
Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
|
Список | 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 по дате отправления: