Обсуждение: BUG #6532: pg_upgrade fails on Python stored procedures
The following bug has been logged on the website: Bug reference: 6532 Logged by: Stuart Bishop Email address: stuart@stuartbishop.net PostgreSQL version: 9.1.3 Operating system: Ubuntu Description:=20=20=20=20=20=20=20=20 The 9.1.3 changelog states pg_upgrade's handing of plpython stored procedures was fixed, but that does not appear to be the case: postgres@aargh:~$ /usr/lib/postgresql/9.1/bin/pg_upgrade --version pg_upgrade (PostgreSQL) 9.1.3 postgres@aargh:~$ /usr/lib/postgresql/9.1/bin/pg_upgrade=20 --old-bindir=3D/usr/lib/postgresql/8.4/bin --new-bindir=3D/usr/lib/postgresql/9.1/bin --old-datadir=3D8.4/main --new-datadir=3D9.1/mig --old-port=3D5433 --new-port=3D5435 Performing Consistency Checks ----------------------------- Checking current, bin, and data directories ok Checking cluster versions ok Checking database user is a superuser ok Checking for prepared transactions ok Checking for reg* system oid user data types ok Checking for contrib/isn with bigint-passing mismatch ok Checking for large objects ok Creating catalog dump ok Checking for prepared transactions ok Checking for presence of required libraries ok | If pg_upgrade fails after this point, you must | re-initdb the new cluster before continuing. | You will also need to remove the ".old" suffix | from 8.4/main/global/pg_control.old. Performing Upgrade ------------------ Adding ".old" suffix to old global/pg_control ok Analyzing all rows in the new cluster ok Freezing all rows on the new cluster ok Deleting new commit clogs ok Copying old commit clogs to new server ok Setting next transaction id for new cluster ok Resetting WAL archives ok Setting frozenxid counters in new cluster ok Creating databases in the new cluster ok Adding support functions to new cluster ok Restoring database schema to new cluster=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 psql:/var/lib/postgresql/pg_upgrade_dump_db.sql:3992: ERROR: could not access file "$libdir/plpython": No such file or directory There were problems executing "/usr/lib/postgresql/9.1/bin/psql" --set ON_ERROR_STOP=3Don --no-psqlrc --port 5435 --username "postgres" -f "/var/lib/postgresql/pg_upgrade_dump_db.sql" --dbname template1 >> "/dev/null" Failure, exiting The relevant section of pg_upgrade_dump_db.sql is: CREATE FUNCTION plpython_call_handler() RETURNS language_handler LANGUAGE c AS '$libdir/plpython', 'plpython_call_handler';
Hi, On Thursday, March 15, 2012 02:13:29 PM stuart@stuartbishop.net wrote: > The 9.1.3 changelog states pg_upgrade's handing of plpython stored > procedures was fixed, but that does not appear to be the case: > ... > access file "$libdir/plpython": No such file or directory Well. That looks like you didn't install plpython on the new cluster. Are you sure its there? Andres
On Thu, Mar 15, 2012 at 8:54 PM, Andres Freund <andres@anarazel.de> wrote: > Hi, > > On Thursday, March 15, 2012 02:13:29 PM stuart@stuartbishop.net wrote: >> The 9.1.3 changelog states pg_upgrade's handing of plpython stored >> procedures was fixed, but that does not appear to be the case: >> ... >> access file "$libdir/plpython": No such file or directory > Well. That looks like you didn't install plpython on the new cluster. Are you > sure its there? Yes, it is there. I can see the library with the new name of plpython2.so, not the old plpython.so from 8.4. createlang installs the language just fine if I build a cluster and database myself. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
On Thu, Mar 15, 2012 at 9:01 PM, Stuart Bishop <stuart@stuartbishop.net> wrote: > Yes, it is there. I can see the library with the new name of > plpython2.so, not the old plpython.so from 8.4. createlang installs > the language just fine if I build a cluster and database myself. As expected, symlinking plpython2.so to plpython.so works around things. I have no idea if this work around will cause problems when upgrading the db to PG 9.2+. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
On Thu, Mar 15, 2012 at 01:13:29PM +0000, stuart@stuartbishop.net wrote: > The following bug has been logged on the website: > > Bug reference: 6532 > Logged by: Stuart Bishop > Email address: stuart@stuartbishop.net > PostgreSQL version: 9.1.3 > Operating system: Ubuntu > Description: > > The 9.1.3 changelog states pg_upgrade's handing of plpython stored > procedures was fixed, but that does not appear to be the case: The change in 9.1.3 was to allow the pg_upgrade code which checks if all the shared librarires are in place to see plpython.so as equivalent to plpython2.so. I did not modify pg_dump at all, which is where you are seeing the error. > There were problems executing "/usr/lib/postgresql/9.1/bin/psql" --set > ON_ERROR_STOP=on --no-psqlrc --port 5435 --username "postgres" -f > "/var/lib/postgresql/pg_upgrade_dump_db.sql" --dbname template1 >> > "/dev/null" > Failure, exiting > > > The relevant section of pg_upgrade_dump_db.sql is: > > CREATE FUNCTION plpython_call_handler() RETURNS language_handler > LANGUAGE c > AS '$libdir/plpython', 'plpython_call_handler'; OK, I am pretty confused by this. Here is all I get in the pg_dumpall --binary-upgrade output for plpython when I create one plpython function: -- -- Name: plpythonu; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: postgres -- CREATE OR REPLACE PROCEDURAL LANGUAGE plpythonu; ALTER PROCEDURAL LANGUAGE plpythonu OWNER TO postgres; SET search_path = public, pg_catalog; -- -- Name: pymax(integer, integer); Type: FUNCTION; Schema: public; Owner: postgres -- CREATE FUNCTION pymax(a integer, b integer) RETURNS integer LANGUAGE plpythonu AS $$ if a > b: return a return b $$; ALTER FUNCTION public.pymax(a integer, b integer) OWNER TO postgres; I have repeatedly upgraded from 9.0.X to 9.1.3 and am seeing no failures. The big question is what are you doing that is causing the plpython_call_handler() function to be dumped? That is an internal function. What is your old PG version? I tested 8.4 and also could not get the failure you see either. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +