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

On Sat, Mar 17, 2012 at 01:57:29AM +0700, Stuart Bishop wrote:
> 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.

Yes, if you delete the public one, you should be fine. If you need
CASCADE, then something is wrong because their is some depenency on it.
Odds are it might have gotten created before we had full schema support
for language or something. The March 5 reporter probably had the same
problem, so isn't just you.

> > 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.

I think we need someone to figure out how this happened before we
actually adjust anything. At least we know what to advise people now.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +