Thread: 9.4 -> 9.5 upgrade problem when both python2 and python3 present
pg_upgrade complains about not being able to find $libdir/plpython3 when upgrading a 9.4 cluster that has both python2 and python3 used. Both the 9.4 and 9.5 PGs have been built from source with python2/3 in the recommended way and the plpython3.so is present in /usr/local/pgsql/lib. I dropped the python2 database but still got the problem. The session: ------------ postgres@mayon:~$ pg_upgrade -b /usr/local/pgsql9.4/bin -B /usr/local/pgsql/bin -d /mnt/pgdata9.4 -D /mnt/pgdata Performing Consistency Checks ----------------------------- Checking cluster versions ok Checking database user is the install user ok Checking database connection settings ok Checking for prepared transactions ok Checking for reg* system OID user data types ok Checking for contrib/isn with bigint-passing mismatch ok Creating dump of global objects ok Creating dump of database schemas ok Checking for presence of required libraries fatal Your installation references loadable libraries that are missing from the new installation. You can add these libraries to the new installation, or remove the functions using them from the old installation. A list of problem libraries is in the file: loadable_libraries.txt Failure, exiting postgres@mayon:~$ cat *.txt Could not load library "$libdir/plpython3" FATAL: Python major version mismatch in session DETAIL: This session has previously used Python major version 2, and it is now attempting to use Python major version 3. HINT: Start a new session to use a different Python major version. server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request.
Paul Jones <pbj@cmicdo.com> writes: > pg_upgrade complains about not being able to find $libdir/plpython3 > when upgrading a 9.4 cluster that has both python2 and python3 used. No, that's not what the error message says: > Could not load library "$libdir/plpython3" > FATAL: Python major version mismatch in session > DETAIL: This session has previously used Python major version 2, and it is now attempting to use Python major version3. > HINT: Start a new session to use a different Python major version. This is a restriction we put in place because libpython2 and libpython3 don't coexist nicely in the same address space. Unfortunately, it makes it problematic to restore a dump that contains references to both python2 and python3 functions. It looks like pg_upgrade tries to load all libraries from functions in any database in the old cluster into a single session in the new cluster, which will fail in a scenario like this even if you keep python2 and python3 functions rigorously separated into distinct databases. I'm not sure if we could weaken that test enough to work. > I dropped the python2 database but still got the problem. You must still have at least one database that contains references to python2 (check pg_language to be sure). regards, tom lane
On Mon, Jan 11, 2016 at 10:04:16AM -0500, Tom Lane wrote: /tmp/mutt-mayon-1000-19386-284b6a00794950f414 > Paul Jones <pbj@cmicdo.com> writes: > > pg_upgrade complains about not being able to find $libdir/plpython3 > > when upgrading a 9.4 cluster that has both python2 and python3 used. > > No, that's not what the error message says: > > > Could not load library "$libdir/plpython3" > > FATAL: Python major version mismatch in session > > DETAIL: This session has previously used Python major version 2, and it is now attempting to use Python major version3. > > HINT: Start a new session to use a different Python major version. > > This is a restriction we put in place because libpython2 and libpython3 > don't coexist nicely in the same address space. Unfortunately, it makes > it problematic to restore a dump that contains references to both python2 > and python3 functions. > > It looks like pg_upgrade tries to load all libraries from functions in > any database in the old cluster into a single session in the new cluster, > which will fail in a scenario like this even if you keep python2 and > python3 functions rigorously separated into distinct databases. I'm > not sure if we could weaken that test enough to work. I guess the thing to do is to manually pg_dump the databases that have python, drop them, upgrade, and then manually restore. > > > I dropped the python2 database but still got the problem. > > You must still have at least one database that contains references > to python2 (check pg_language to be sure). I thought of that after I pulled the trigger on the mail... Thanks for the information... > > regards, tom lane > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general
Paul Jones <pbj@cmicdo.com> writes: > On Mon, Jan 11, 2016 at 10:04:16AM -0500, Tom Lane wrote: >> It looks like pg_upgrade tries to load all libraries from functions in >> any database in the old cluster into a single session in the new cluster, >> which will fail in a scenario like this even if you keep python2 and >> python3 functions rigorously separated into distinct databases. I'm >> not sure if we could weaken that test enough to work. > I guess the thing to do is to manually pg_dump the databases that have > python, drop them, upgrade, and then manually restore. If you'd rather build a patched version of PG, I have posted a work-in-progress patch to address this issue: http://www.postgresql.org/message-id/31659.1452538805@sss.pgh.pa.us regards, tom lane
On Mon, Jan 11, 2016 at 06:23:06PM -0500, Tom Lane wrote: > Date: Mon, 11 Jan 2016 18:23:06 -0500 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: Paul Jones <pbj@cmicdo.com> > cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] 9.4 -> 9.5 upgrade problem when both python2 and > python3 present > > > > I guess the thing to do is to manually pg_dump the databases that have > > python, drop them, upgrade, and then manually restore. > > If you'd rather build a patched version of PG, I have posted a > work-in-progress patch to address this issue: > http://www.postgresql.org/message-id/31659.1452538805@sss.pgh.pa.us It worked most excellently, thank you. > > regards, tom lane