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

From: GMX LINREG <linreg(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 16:40:46
Message-ID: 7912997.NyiUUSuA9g@wolfclan.ang.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Am Freitag, 29. Januar 2021, 16:04:54 CET schrieb Tom Lane:
> GMX Steffen <steffen(dot)ang(at)gmx(dot)de> writes:
> > OS Packages:
> > *postgresql*-llvmjit-13-lp152.3.1.noarch
> > *postgresql*12-pldebugger-1.0+git13.ddbce7b-lp152.1.4.x86_64
> > *postgresql*12-llvmjit-12.5-lp152.34.1.x86_64
> > *postgresql*-13-lp152.3.1.noarch
> > *postgresql*12-docs-12.5-lp152.34.1.noarch
> > *postgresql*12-contrib-12.5-lp152.34.1.x86_64
> > *postgresql*13-plperl-13.1-lp152.16.1.x86_64
> > *postgresql*12-server-12.5-lp152.34.1.x86_64
> > *postgresql*-docs-13-lp152.3.1.noarch
> > *postgresql*12-12.5-lp152.34.1.x86_64
> > *postgresql*12-pg_qualstats-2.0.2-lp152.2.3.x86_64
> > *postgresql*12-ip4r-2.4.1+git1.5f9ce88-lp152.8.2.x86_64
> > *postgresql*-server-13-lp152.3.1.noarch
> > *postgresql*12-pg_qualstats-llvmjit-2.0.2-lp152.2.3.x86_64
> > *postgresql*13-docs-13.1-lp152.16.1.noarch
> > *postgresql*13-server-13.1-lp152.16.1.x86_64
> > *postgresql*-contrib-13-lp152.3.1.noarch
> > *postgresql*12-ip4r-llvmjit-2.4.1+git1.5f9ce88-lp152.8.2.x86_64
> > *postgresql*13-13.1-lp152.16.1.x86_64
> > *postgresql*13-llvmjit-13.1-lp152.16.1.x86_64
> > *postgresql*-plperl-13-lp152.3.1.noarch
> > *postgresql*12-pldebugger-llvmjit-1.0+git13.ddbce7b-lp152.1.4.x86_64
> > *postgresql*13-contrib-13.1-lp152.16.1.x86_64
>
> This ... looks like a bit of a mess. You evidently have three independent
> sets of Postgres packages, but surely there should only be two. And
> why do they all have "lp152" in the version? (And why are there only
> two versions of plperl? And why are some of these "noarch"? That
> would make sense for the docs subpackage, but not much else.)
>
> The pg_restore trace gives us no more info than we had before. But
> given this package list, I am suspecting some confusion over which
> version of plperl.so should get loaded. You might try looking into
> the destination postmaster's log file (not pg_upgrade's user-visible
> output) to see if there is any low-level message from the dynamic
> loader emitted just before it complains about plperlu not existing.
>
> regards, tom lane

Hello,

- packages like "postgresql*-contrib-13-lp152.3.1.noarch" are meta packages (noarch) and depend to actual installed version. in this case version 13.
- lp152 is a label for opensuse leap 15.2

- when run version 12 it use /usr/lib/postgresql12/lib64/plperl.so
for version 13 it's use /usr/lib/postgresql13/lib64/plperl.so

- there is no low-level message from the dynamic loader. the extension can created everytime. And exist in the upgraded database

i hope you could read my last email: i resend three times :(
There you can see this:

psql (13.1)
Geben Sie »help« für Hilfe ein.

botdb=# \dL
Liste der Sprachen
Name | Eigentümer | Vertraut | Beschreibung
---------+------------+----------+------------------------------
plpgsql | postgres | t | PL/pgSQL procedural language
(1 Zeile)

==> NO LANGUAGE PLPERLU! "CREATE LANGUAGE plperlu" ==> create ONLY an extension!

botdb=# \dx
Liste der installierten Erweiterungen
Name | Version | Schema | Beschreibung
--------------+---------+------------+--------------------------------------------------
hstore | 1.5 | pg_catalog | data type for storing sets of (key, value) pairs
pg_cron | 4.0.4 | public | Cron-like Job Scheduler for PostgreSQL
pg_http | 1.4.1 | public | A web service for PostgreSQL
pg_mqtt | 1.1 | public | A mqtt client daemon for PostgreSQL
pg_reporting | 1.1 | public | A reporting extension for PostgreSQL
plperlu | 1.0 | pg_catalog | PL/PerlU untrusted procedural language <====
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(7 Zeilen)

==> EXTENSION plperlu ALREADY CREATED AND EXIST

The command "create language" create NO plperlu language object. ONLY a extension object. Correct?
Therefor it must fail to add a language to an extension! And i think the "create extension" run fine, so that the command alter extension / add language combination is only for older postgresql version okay. it is not needed any more.
The failed upgraded database has the extension plperlu installed! So this is fine too.

best regards thomas steffen

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-01-29 17:29:34 Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
Previous Message Tom Lane 2021-01-29 15:04:54 Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed