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

On Sat, Mar 17, 2012 at 12:54 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> Well, it will because, by creating the symlink, you allowed this
> function to be restored into the new database, and it isn't properly
> hooked to the plpython language.  I wonder if you should just delete it
> because I believe you already have the right plpython2 helper functions
> in place.  Can you run this query for me in one of the problem databases
> in the new and/or old cluster and send me the output:
>
>        SELECT proname,probin FROM pg_proc WHERE probin LIKE '%python%';

# SELECT nspname,proname,probin FROM pg_proc,pg_namespace WHERE probin
LIKE '%python%' and pg_proc.pronamespace=pg_namespace.oid;
nspname | proname | probin
------------+-----------------------+------------------
pg_catalog | plpython_call_handler | $libdir/plpython
public | plpython_call_handler | $libdir/plpython
(2 rows)

I have no idea how I managed to grow the duplicate in the public
schema, but this does seem to be the source of the confusion. I might
be able to dig out when I grew it from revision control, but I don't
think that would help.

> What we need is for pg_dumpall to _not_ output those handlers.

Or pick it up in the check stage and make the user resolve the
problem. If I shot myself in the foot in some particularly obtuse way,
it might not be sane to bend over backwards making pg_upgrade repair
things.

--
Stuart Bishop <stuart(at)stuartbishop(dot)net>
http://www.stuartbishop.net/