On Sat, Mar 17, 2012 at 12:54 AM, Bruce Momjian <bruce@momjian.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/plpythonpublic
|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@stuartbishop.net>
http://www.stuartbishop.net/
