From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Stuart Bishop <stuart(at)stuartbishop(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures |
Date: | 2012-03-16 18:08:53 |
Message-ID: | 20120316180853.GA14587@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Stuart Bishop | 2012-03-16 18:57:29 | Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures |
Previous Message | Tom Lane | 2012-03-16 17:56:44 | Re: BUG #6535: LEFT JOIN on large table is altering data |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-03-16 18:15:11 | Re: foreign key locks, 2nd attempt |
Previous Message | Bruce Momjian | 2012-03-16 17:54:02 | Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures |