Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures

On Fri, Mar 16, 2012 at 03:10:05PM +0700, Stuart Bishop wrote:
> > 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.
> 
> This database schema began its life on PostgreSQL 7.4 over 8 years
> ago, so there may well be something unexpected lurking in there.

[ Email moved to hackers, and trimmed.]

That might be the cause --- see my posting asking for details.

> I can reproduce the error with the attached schema. It was created
> using 8.4's pg_dump. If I create a fresh 8.4 cluster and restore this,
> pg_dump and pg_dumpall spit out the plpython_call_handler statements.
> I think I've stripped out everything in there not in core or contrib.

Thanks.  Yes, this actually does show the cause:
> --> -- Name: plpgsql_call_handler(); Type: FUNCTION; Schema: public; Owner: -> --> > CREATE FUNCTION
plpgsql_call_handler()RETURNS language_handler>     LANGUAGE c>     AS '$libdir/plpgsql', 'plpgsql_call_handler';> > >
-->-- Name: plpython_call_handler(); Type: FUNCTION; Schema: public; Owner: -> --
                ******> > CREATE FUNCTION plpython_call_handler() RETURNS language_handler>     LANGUAGE c>     AS
'$libdir/plpython','plpython_call_handler';> 
 

Notice these are all in the public schema, which is causing pg_dumpall
to output them, and the rename of plpython is causing the failure.  Do
you have these functions also in the pg_catalog schema?  If so, they
must be dead functions left over from an old release of Postgres.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +