On Sat, May 26, 2012 at 11:42:09PM +0000, adrian.klaver@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6666
> Logged by: Adrian Klaver
> Email address: adrian.klaver@gmail.com
> PostgreSQL version: 9.0.7
> Operating system: Linux/OpenSuse 12.1
> Description:
>
> I thought this was fixed in:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=cfe443ab9d42b4ffe950608f01c3a4bdc2895c7b
>
> I just tried an upgrade from 9.0.7 to 9.2beta1 using pg_upgrade. I ran it
> first with -c and everything passed. When I did a live upgrade it failed
> with this message in pg_upgrade_restore.log:
>
> CREATE FUNCTION plpython_call_handler() RETURNS language_handler
> LANGUAGE c
> AS '$libdir/plpython', 'plpython_call_handler';
> psql:pg_upgrade_dump_db.sql:13541: ERROR: could not access file
> "$libdir/plpython": No such file or directory
>
> That is indeed true, there is no plpython, there is plpython2 instead. I
> created a symlink plpython --> plpython2 and the upgraded succeeded after a
> re-initdb of the new cluster.
It took me a little while to remember the cause of this problem, but I
found it!
http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php
This was reported in March, 2012 --- please read the entire thread. The
problem is that you have a plpython_call_handler defined in the "public"
schema, and it is being dumped out by pg_dumpall, rather than using a
generic CREATE LANGUAGE statement. Odds are this is left over from an
older version of Postgres.
If you can help me find out how these got defined this way, I might be
able to prevent this problem for the next person.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
