pg_upgrade from 12 to 13 failes with plpython2
Hi all, trying to performe upgrade from 12 to 13 installed from Centos8 repo gives such error:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
digging around:
1.
drop extension plpythonu;
ERROR: extension "plpythonu" does not exist
2.
postgres=# select * from pg_pltemplate ;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplinline | tmplvalidator | tmpllibrary | tmplacl
------------+-------------+---------------+------------------------+--------------------------+---------------------+-------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_inline_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_inline_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperlu_call_handler | plperlu_inline_handler | plperlu_validator | $libdir/plperl |
plpythonu | f | f | plpython_call_handler | plpython_inline_handler | plpython_validator | $libdir/plpython2 |
plpython2u | f | f | plpython2_call_handler | plpython2_inline_handler | plpython2_validator | $libdir/plpython2 |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 |
(8 rows)
3.
postgres=# select * from pg_language ;
oid | lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
-------+----------+----------+---------+--------------+---------------+-----------+--------------+--------
12 | internal | 10 | f | f | 0 | 0 | 2246 |
13 | c | 10 | f | f | 0 | 0 | 2247 |
14 | sql | 10 | f | t | 0 | 0 | 2248 |
14177 | plpgsql | 10 | t | t | 14174 | 14175 | 14176 |
(4 rows)
4.
postgres=# select DISTINCT l.lanname as function_language
postgres-# from pg_proc p
postgres-# left join pg_language l on p.prolang = l.oid;
function_language
-------------------
c
sql
internal
(3 rows)
5.
postgres=# SELECT oid::regprocedure
postgres-# FROM pg_catalog.pg_proc
postgres-# WHERE probin = '$libdir/plpython2';
oid
-----
(0 rows)
Question: where is plpython2 comming from during pg_upgrade? Is this pg_upgrade bug or something else?
Thx
Marcin
Hi,
On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote:
Hi all, trying to performe upgrade from 12 to 13 installed from
Centos8 repo gives such error:cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access
file "$libdir/plpython2": No such file or directory
I dropped PL/Python support along with PostgreSQL 13 RPMs.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org> writes:
On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote:
Hi all, trying to performe upgrade from 12 to 13 installed from
Centos8 repo gives such error:cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access
file "$libdir/plpython2": No such file or directory
I dropped PL/Python support along with PostgreSQL 13 RPMs.
Yeah, I tried to stir up some interest in having a cleaner python 2
to python 3 migration path, but there wasn't any. Best bet probably
is to convert your plpython[2] functions to plpython3 before you
upgrade.
regards, tom lane
On 11/17/20 12:06 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 21:00 +0100, Marcin Giedz wrote:
Hi all, trying to performe upgrade from 12 to 13 installed from
Centos8 repo gives such error:cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access
file "$libdir/plpython2": No such file or directoryI dropped PL/Python support along with PostgreSQL 13 RPMs.
This was announced where and when?
Regards,
--
Adrian Klaver
adrian.klaver@aklaver.com
Hi,
On Tue, 2020-11-17 at 12:18 -0800, Adrian Klaver wrote:
This was announced where and when?
/messages/by-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel@gunduz.org
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On 11/17/20 12:49 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 12:18 -0800, Adrian Klaver wrote:
This was announced where and when?
/messages/by-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel@gunduz.org
So to be clear what was dropped was plpythonu, which means plpython2u.
plpython3u still exists, correct?
It would be nice to mention this on --announce and here as this still
exists:
https://www.postgresql.org/docs/13/plpython-python23.html
"
Existing users and users who are currently not interested in Python 3
use the language name plpythonu and don't have to change anything for
the foreseeable future. It is recommended to gradually “future-proof”
the code via migration to Python 2.6/2.7 to simplify the eventual
migration to Python 3.
In practice, many PL/Python functions will migrate to Python 3 with few
or no changes.
"
Regards,
--
Adrian Klaver
adrian.klaver@aklaver.com
Hi,
On Tue, 2020-11-17 at 13:18 -0800, Adrian Klaver wrote:
/messages/by-id/333f3aa334ba93019c75fffaec373f2bf4275d28.camel@gunduz.org
So to be clear what was dropped was plpythonu, which means
plpython2u. plpython3u still exists, correct?
Right.
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Adrian Klaver <adrian.klaver@aklaver.com> writes:
It would be nice to mention this on --announce and here as this still
exists:
https://www.postgresql.org/docs/13/plpython-python23.html
You're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support.
The packagers frequently don't have a lot of choice in the matter;
once their platform drops python2, they can't support plpython2.
regards, tom lane
On 11/17/20 1:23 PM, Tom Lane wrote:
Adrian Klaver <adrian.klaver@aklaver.com> writes:
It would be nice to mention this on --announce and here as this still
exists:
https://www.postgresql.org/docs/13/plpython-python23.htmlYou're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support.
The packagers frequently don't have a lot of choice in the matter;
once their platform drops python2, they can't support plpython2.
But CentOS/RH have not dropped Python 2, they have just made Python 3
the default:
https://www.liquidweb.com/kb/how-to-install-python-on-centos-8/
regards, tom lane
--
Adrian Klaver
adrian.klaver@aklaver.com
Hi,
On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote:
You're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support.
The packagers frequently don't have a lot of choice in the matter;
once their platform drops python2, they can't support plpython2.
Well, CentOS 8 "supports" PY2, however given that Christoph also
dropped PY2 support in Debian packages as of PostgreSQL 12 [1]/messages/by-id/20200522080114.GA449430@msg.df7cb.de, and
given that *Python 2 is unsupported* anyway, I just wanted to drop
support at this point.
FWIW, older PostgreSQL major versions still have PY 2 support. This is
for PostgreSQL 13 only.
[1]: /messages/by-id/20200522080114.GA449430@msg.df7cb.de
Regards,
--
Devrim Gündüz
Open Source Solution Architect, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
On 11/17/20 2:17 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote:
You're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support.
The packagers frequently don't have a lot of choice in the matter;
once their platform drops python2, they can't support plpython2.
First let me say:
1) I don't use Python 2 anymore.
2) I have converted my plpython(2)u functions to plpythonu3u
3) I don't use RH family distros.
Well, CentOS 8 "supports" PY2, however given that Christoph also
dropped PY2 support in Debian packages as of PostgreSQL 12 [1], and
given that *Python 2 is unsupported* anyway, I just wanted to drop
support at this point.
Read that sentence again and see the inherent disconnect between the
beginning and end.
As a packager you are in charge of how the packaging is done. Still
announcing a change that effectively nullifies the documentation would
to me be something that should be announced somewhere else than a list
that I'm guessing 99% of the users don't read.
FWIW, older PostgreSQL major versions still have PY 2 support. This is
for PostgreSQL 13 only.
[1] : /messages/by-id/20200522080114.GA449430@msg.df7cb.de
Regards,
--
Adrian Klaver
adrian.klaver@aklaver.com
but my question still remains the same - what causes pg_upgrade failure - are functions the reason? what I did was to delete these 2 rows from pg_pltemplate as I thought this may help:
postgres=# delete from pg_pltemplate where tmplname = 'plpython2u';
DELETE 1
postgres=# delete from pg_pltemplate where tmplname = 'plpythonu';
DELETE 1
but pg_upgrade still complains about plpython2:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: alaxx
In database: template1
marcin@carbon2:~$ psql -U pgsql -h 192.168.89.64 alaxx
psql (12.4 (Ubuntu 12.4-1))
Type "help" for help.
argosrm=# select * from pg_pltemplate ;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplinline | tmplvalidator | tmpllibrary | tmplacl
------------+-------------+---------------+------------------------+--------------------------+---------------------+-------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_inline_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_inline_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperlu_call_handler | plperlu_inline_handler | plperlu_validator | $libdir/plperl |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 |
(6 rows)
argosrm=# \q
marcin@carbon2:~$ psql -U pgsql -h 192.168.89.64 template1
psql (12.4 (Ubuntu 12.4-1))
Type "help" for help.
template1=# select * from pg_pltemplate ;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplinline | tmplvalidator | tmpllibrary | tmplacl
------------+-------------+---------------+------------------------+--------------------------+---------------------+-------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_inline_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_inline_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperlu_call_handler | plperlu_inline_handler | plperlu_validator | $libdir/plperl |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 |
(6 rows)
what can I do next ?
Thx
Marcin
Od: "Adrian Klaver" <adrian.klaver@aklaver.com>
Do: "Devrim Gündüz" <devrim@gunduz.org>, "Tom Lane" <tgl@sss.pgh.pa.us>
DW: "Marcin Giedz" <marcin.giedz@arise.pl>, "pgsql-general" <pgsql-general@lists.postgresql.org>
Wysłane: wtorek, 17 listopad 2020 23:30:44
Temat: Re: pg_upgrade from 12 to 13 failes with plpython2
On 11/17/20 2:17 PM, Devrim Gündüz wrote:
Hi,
On Tue, 2020-11-17 at 16:23 -0500, Tom Lane wrote:
You're confusing what the source code can do (which is what the
manual documents) versus what individual packagers choose to support.
The packagers frequently don't have a lot of choice in the matter;
once their platform drops python2, they can't support plpython2.
First let me say:
1) I don't use Python 2 anymore.
2) I have converted my plpython(2)u functions to plpythonu3u
3) I don't use RH family distros.
Well, CentOS 8 "supports" PY2, however given that Christoph also
dropped PY2 support in Debian packages as of PostgreSQL 12 [1], and
given that *Python 2 is unsupported* anyway, I just wanted to drop
support at this point.
Read that sentence again and see the inherent disconnect between the
beginning and end.
As a packager you are in charge of how the packaging is done. Still
announcing a change that effectively nullifies the documentation would
to me be something that should be announced somewhere else than a list
that I'm guessing 99% of the users don't read.
FWIW, older PostgreSQL major versions still have PY 2 support. This is
for PostgreSQL 13 only.
[1] : /messages/by-id/20200522080114.GA449430@msg.df7cb.de
Regards,
--
Adrian Klaver
adrian.klaver@aklaver.com
--
Pozdrawiam
Marcin Giedz
Wiceprezes Zarządu
ARISE Sp. z o.o.
mob. +48 606 673 977
mail: marcin.giedz@arise.pl
Al. Solidarności 117
00-140 Warszawa
tel. +48 (22) 440 56 20
fax +48 (22) 440 56 22
http://www.arise.pl
Grupa ARISE: ARISE Sp. z o.o. (podmiot dominujący), ARISE Services S.A., Al. Solidarności 117, 00-140 Warszawa, Sąd Rejonowy dla m. st. Warszawy w Warszawie XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000316860, REGON 141595449, NIP 5272590610, kapitał zakładowy wpłacony 250,000.00 zł.
On Wed, Nov 18, 2020 at 8:11 AM Marcin Giedz <marcin.giedz@arise.pl> wrote:
but my question still remains the same - what causes pg_upgrade failure - are functions the reason? what I did was to delete these 2 rows from pg_pltemplate as I thought this may help:
postgres=# delete from pg_pltemplate where tmplname = 'plpython2u';
DELETE 1
postgres=# delete from pg_pltemplate where tmplname = 'plpythonu';
DELETE 1but pg_upgrade still complains about plpython2:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: alaxx
In database: template1
It's not the template that's interesting, it's the language itself you
need to drop. Log into each database and try to do that, and you will
get something like this if you still have functions using it:
postgres=# DROP LANGUAGE plpython2u;
ERROR: cannot drop language plpython2u because other objects depend on it
DETAIL: function testfunc() depends on language plpython2u
HINT: Use DROP ... CASCADE to drop the dependent objects too.
If you have no functions using it, it will just go away, and once you
have dropped it in both databases you should be good to go.
And of course, if there are functions depending on it, you should
rebuild those on plpython3u before you drop plpython2u (or drop the
functions if they're not in use).
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
right, I had one function relaying on plpython2u so I changed it... but the again pg_upgrade claims error with python:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: argosrm
In database: template1
marcin@carbon2:~$ psql -U pgsql -h 192.168.89.64 postgres
psql (12.4 (Ubuntu 12.4-1), server 12.5)
Type "help" for help.
postgres=# select * from pg_language ;
oid | lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
-------+----------+----------+---------+--------------+---------------+-----------+--------------+--------
12 | internal | 10 | f | f | 0 | 0 | 2246 |
13 | c | 10 | f | f | 0 | 0 | 2247 |
14 | sql | 10 | f | t | 0 | 0 | 2248 |
14177 | plpgsql | 10 | t | t | 14174 | 14175 | 14176 |
(4 rows)
postgres=# \c argosrm
psql (12.4 (Ubuntu 12.4-1), server 12.5)
You are now connected to database "argosrm" as user "pgsql".
argosrm=# select * from pg_language ;
oid | lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
---------+------------+----------+---------+--------------+---------------+-----------+--------------+--------
12 | internal | 10 | f | f | 0 | 0 | 2246 |
13 | c | 10 | f | f | 0 | 0 | 2247 |
14 | sql | 10 | f | t | 0 | 0 | 2248 |
14177 | plpgsql | 10 | t | t | 14174 | 14175 | 14176 |
1824389 | plpython3u | 10 | t | f | 1824386 | 1824387 | 1824388 |
(5 rows)
argosrm=# \c template1
psql (12.4 (Ubuntu 12.4-1), server 12.5)
You are now connected to database "template1" as user "pgsql".
template1=# select * from pg_language ;
oid | lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
-------+----------+----------+---------+--------------+---------------+-----------+--------------+--------
12 | internal | 10 | f | f | 0 | 0 | 2246 |
13 | c | 10 | f | f | 0 | 0 | 2247 |
14 | sql | 10 | f | t | 0 | 0 | 2248 |
14177 | plpgsql | 10 | t | t | 14174 | 14175 | 14176 |
(4 rows)
template1=# drop language plpython2u;
ERROR: language "plpython2u" does not exist
template1=# drop language plpython;
ERROR: language "plpython" does not exist
template1=# drop language plpythonu;
ERROR: language "plpythonu" does not exist
template1=# \c postgres
psql (12.4 (Ubuntu 12.4-1), server 12.5)
You are now connected to database "postgres" as user "pgsql".
postgres=# drop language plpythonu;
ERROR: language "plpythonu" does not exist
postgres=# drop language plpython;
ERROR: language "plpython" does not exist
postgres=# drop language plpython2u;
ERROR: language "plpython2u" does not exist
postgres=# \c argosrm
psql (12.4 (Ubuntu 12.4-1), server 12.5)
You are now connected to database "argosrm" as user "pgsql".
argosrm=# drop language plpython2u;
ERROR: language "plpython2u" does not exist
argosrm=# drop language plpython;
ERROR: language "plpython" does not exist
argosrm=# drop language plpythonu;
ERROR: language "plpythonu" does not exist
argosrm=#
argosrm=# select * from pg_pltemplate ;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplinline | tmplvalidator | tmpllibrary | tmplacl
------------+-------------+---------------+------------------------+--------------------------+---------------------+-------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_inline_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_inline_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperlu_call_handler | plperlu_inline_handler | plperlu_validator | $libdir/plperl |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 |
(6 rows)
argosrm=# \c postgres
psql (12.4 (Ubuntu 12.4-1), server 12.5)
You are now connected to database "postgres" as user "pgsql".
postgres=# select * from pg_pltemplate ;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplinline | tmplvalidator | tmpllibrary | tmplacl
------------+-------------+---------------+------------------------+--------------------------+---------------------+-------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_inline_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_inline_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperlu_call_handler | plperlu_inline_handler | plperlu_validator | $libdir/plperl |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 |
(6 rows)
postgres=# \c template1
psql (12.4 (Ubuntu 12.4-1), server 12.5)
You are now connected to database "template1" as user "pgsql".
template1=# select * from pg_pltemplate ;
tmplname | tmpltrusted | tmpldbacreate | tmplhandler | tmplinline | tmplvalidator | tmpllibrary | tmplacl
------------+-------------+---------------+------------------------+--------------------------+---------------------+-------------------+---------
plpgsql | t | t | plpgsql_call_handler | plpgsql_inline_handler | plpgsql_validator | $libdir/plpgsql |
pltcl | t | t | pltcl_call_handler | | | $libdir/pltcl |
pltclu | f | f | pltclu_call_handler | | | $libdir/pltcl |
plperl | t | t | plperl_call_handler | plperl_inline_handler | plperl_validator | $libdir/plperl |
plperlu | f | f | plperlu_call_handler | plperlu_inline_handler | plperlu_validator | $libdir/plperl |
plpython3u | f | f | plpython3_call_handler | plpython3_inline_handler | plpython3_validator | $libdir/plpython3 |
(6 rows)
template1=#
Od: "Magnus Hagander" <magnus@hagander.net>
Do: "Marcin Giedz" <marcin.giedz@arise.pl>
DW: "Adrian Klaver" <adrian.klaver@aklaver.com>, "Tom Lane" <tgl@sss.pgh.pa.us>, "Devrim Gündüz" <devrim@gunduz.org>, "pgsql-general" <pgsql-general@lists.postgresql.org>
Wysłane: środa, 18 listopad 2020 10:36:10
Temat: Re: pg_upgrade from 12 to 13 failes with plpython2
On Wed, Nov 18, 2020 at 8:11 AM Marcin Giedz <marcin.giedz@arise.pl> wrote:
but my question still remains the same - what causes pg_upgrade failure - are functions the reason? what I did was to delete these 2 rows from pg_pltemplate as I thought this may help:
postgres=# delete from pg_pltemplate where tmplname = 'plpython2u';
DELETE 1
postgres=# delete from pg_pltemplate where tmplname = 'plpythonu';
DELETE 1but pg_upgrade still complains about plpython2:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: alaxx
In database: template1
It's not the template that's interesting, it's the language itself you
need to drop. Log into each database and try to do that, and you will
get something like this if you still have functions using it:
postgres=# DROP LANGUAGE plpython2u;
ERROR: cannot drop language plpython2u because other objects depend on it
DETAIL: function testfunc() depends on language plpython2u
HINT: Use DROP ... CASCADE to drop the dependent objects too.
If you have no functions using it, it will just go away, and once you
have dropped it in both databases you should be good to go.
And of course, if there are functions depending on it, you should
rebuild those on plpython3u before you drop plpython2u (or drop the
functions if they're not in use).
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
--
Pozdrawiam
Marcin Giedz
Wiceprezes Zarządu
ARISE Sp. z o.o.
mob. +48 606 673 977
mail: marcin.giedz@arise.pl
Al. Solidarności 117
00-140 Warszawa
tel. +48 (22) 440 56 20
fax +48 (22) 440 56 22
http://www.arise.pl
Grupa ARISE: ARISE Sp. z o.o. (podmiot dominujący), ARISE Services S.A., Al. Solidarności 117, 00-140 Warszawa, Sąd Rejonowy dla m. st. Warszawy w Warszawie XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000316860, REGON 141595449, NIP 5272590610, kapitał zakładowy wpłacony 250,000.00 zł.
On Wed, 2020-11-18 at 11:05 +0100, Marcin Giedz wrote:
right, I had one function relaying on plpython2u so I changed it... but the again pg_upgrade claims error with python:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: argosrm
In database: template1
The problematic function is perhaps in another database.
Look everywhere.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
Hi, not the case I believe :
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+-------+----------+-------------+-------------+-------------------
argosrm | pgsql | UTF8 | pl_PL.UTF-8 | pl_PL.UTF-8 |
postgres | pgsql | UTF8 | pl_PL.UTF-8 | pl_PL.UTF-8 |
template0 | pgsql | UTF8 | pl_PL.UTF-8 | pl_PL.UTF-8 | =c/pgsql +
| | | | | pgsql=CTc/pgsql
template1 | pgsql | UTF8 | pl_PL.UTF-8 | pl_PL.UTF-8 | =c/pgsql +
| | | | | pgsql=CTc/pgsql
(4 rows)
all DBs checked and no plpython(2u) is found except for plpython3u
...
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: argosrm
In database: template1
Thx
M.
Od: "Laurenz Albe" <laurenz.albe@cybertec.at>
Do: "Marcin Giedz" <marcin.giedz@arise.pl>, "Magnus Hagander" <magnus@hagander.net>
DW: "Adrian Klaver" <adrian.klaver@aklaver.com>, "Tom Lane" <tgl@sss.pgh.pa.us>, "Devrim Gündüz" <devrim@gunduz.org>, "pgsql-general" <pgsql-general@lists.postgresql.org>
Wysłane: środa, 18 listopad 2020 12:58:45
Temat: Re: pg_upgrade from 12 to 13 failes with plpython2
On Wed, 2020-11-18 at 11:05 +0100, Marcin Giedz wrote:
right, I had one function relaying on plpython2u so I changed it... but the again pg_upgrade claims error with python:
cat loadable_libraries.txt
could not load library "$libdir/plpython2": ERROR: could not access file "$libdir/plpython2": No such file or directory
In database: argosrm
In database: template1
The problematic function is perhaps in another database.
Look everywhere.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
Marcin Giedz <marcin.giedz@arise.pl> writes:
all DBs checked and no plpython(2u) is found except for plpython3u
I think you also need to make sure you've dropped the plpythonu
and plpython2u extensions in every database.
regards, tom lane
so look at this:
marcin@carbon2:~$ psql -U pgsql -h 192.168.89.64 postgres
psql (12.4 (Ubuntu 12.4-1), server 12.5)
Type "help" for help.
postgres=# drop extension plpython;
ERROR: extension "plpython" does not exist
postgres=# drop extension plpythonu;
ERROR: extension "plpythonu" does not exist
postgres=# drop extension plpython2u;
ERROR: extension "plpython2u" does not exist
postgres=# \q
marcin@carbon2:~$ psql -U pgsql -h 192.168.89.64 template1
psql (12.4 (Ubuntu 12.4-1), server 12.5)
Type "help" for help.
template1=# drop extension plpython2u;
ERROR: extension "plpython2u" does not exist
template1=# drop extension plpythonu;
ERROR: extension "plpythonu" does not exist
template1=# drop extension plpython;
ERROR: extension "plpython" does not exist
template1=# \q
marcin@carbon2:~$ psql -U pgsql -h 192.168.89.64 argosrm
psql (12.4 (Ubuntu 12.4-1), server 12.5)
Type "help" for help.
argosrm=# drop extension plpython;
ERROR: extension "plpython" does not exist
argosrm=# drop extension plpythonu;
ERROR: extension "plpythonu" does not exist
argosrm=# drop extension plpython2u;
ERROR: extension "plpython2u" does not exist
Od: "Tom Lane" <tgl@sss.pgh.pa.us>
Do: "Marcin Giedz" <marcin.giedz@arise.pl>
DW: "Laurenz Albe" <laurenz.albe@cybertec.at>, "Magnus Hagander" <magnus@hagander.net>, "Adrian Klaver" <adrian.klaver@aklaver.com>, "Devrim Gündüz" <devrim@gunduz.org>, "pgsql-general" <pgsql-general@lists.postgresql.org>
Wysłane: środa, 18 listopad 2020 19:08:25
Temat: Re: pg_upgrade from 12 to 13 failes with plpython2
Marcin Giedz <marcin.giedz@arise.pl> writes:
all DBs checked and no plpython(2u) is found except for plpython3u
I think you also need to make sure you've dropped the plpythonu
and plpython2u extensions in every database.
regards, tom lane
[ please don't top-post, it makes conversations unreadable ]
Marcin Giedz <marcin.giedz@arise.pl> writes:
so look at this:
postgres=# drop extension plpython;
ERROR: extension "plpython" does not exist
postgres=# drop extension plpythonu;
ERROR: extension "plpythonu" does not exist
postgres=# drop extension plpython2u;
ERROR: extension "plpython2u" does not exist
Well, the pg_upgrade failure clearly shows that you've got some
functions referencing plpython2. Maybe they're "loose" instead
of being bound into an extension --- that's quite possible if
this database has been brought forward from some pre-9.1 state.
Try looking in each database with
select * from pg_proc where probin like '%python2%';
regards, tom lane
[ please don't top-post, it makes conversations unreadable ]
Marcin Giedz <marcin.giedz@arise.pl> writes:
so look at this:
postgres=# drop extension plpython;
ERROR: extension "plpython" does not exist
postgres=# drop extension plpythonu;
ERROR: extension "plpythonu" does not exist
postgres=# drop extension plpython2u;
ERROR: extension "plpython2u" does not exist
Well, the pg_upgrade failure clearly shows that you've got some
functions referencing plpython2. Maybe they're "loose" instead
of being bound into an extension --- that's quite possible if
this database has been brought forward from some pre-9.1 state.
Try looking in each database with
select * from pg_proc where probin like '%python2%';
regards, tom lane
--------------------------------------------------------------------------------------------------------------------------------
sorry for top-posting not a day-to-day habits in our env ;)
anyway got this from your query:
oid | proname | pronamespace | proowner | prolang | procost | prorows | provariadic | prosupport | prokind | prosecdef | proleakproof | proisstrict | proretset | provolatile | proparallel | pronargs | pronargdefaults | prorettype | proargtypes | proallargtypes | proargmodes | proargnames | proargdefaults | protrftypes | prosrc | probin | proconfig | proacl
-------+-------------------------+--------------+----------+---------+---------+---------+-------------+------------+---------+-----------+--------------+-------------+-----------+-------------+-------------+----------+-----------------+------------+-------------+----------------+-------------+-------------+----------------+-------------+-------------------------+-------------------+-----------+--------
16402 | plpython_call_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | f | f | v | u | 0 | 0 | 2280 | | | | | | | plpython_call_handler | $libdir/plpython2 | |
16403 | plpython_inline_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | t | f | v | u | 1 | 0 | 2278 | 2281 | | | | | | plpython_inline_handler | $libdir/plpython2 | |
16404 | plpython_validator | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | t | f | v | u | 1 | 0 | 2278 | 26 | | | | | | plpython_validator | $libdir/plpython2 | |
(3 rows)
(END)
sounds nothing for me I'm afraid but I hope gives a hint for you ;)
Many thx
M.
