On Sat, Mar 17, 2012 at 12:54 AM, Bruce Momjian <br...@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/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 <stu...@stuartbishop.net> http://www.stuartbishop.net/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
