Skip site navigation (1) Skip section navigation (2)

Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2

From: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Date: 2012-05-30 02:13:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On 05/29/2012 05:44 PM, Bruce Momjian wrote:
> On Sun, May 27, 2012 at 11:49:31AM -0700, Adrian Klaver wrote:
>>> If you can help me find out how these got defined this way, I might be
>>> able to prevent this problem for the next person.
>> After reading the above thread here is what the queries mentioned return:
>> production=#  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
>>   pg_catalog | plpython_inline_handler | $libdir/plpython
>>   public     | plpython_call_handler   | $libdir/plpython
>> (3 rows)
> You are the third person to have this problem, and this was the
> information I needed to properly find the cause.  I believe it was done
> in this 8.1 commit:
>      e0dedd0559f005d60c69c9772163e69c204bac69
>      Implement a preliminary 'template' facility for procedural languages,
>      as per my recent proposal.  For now the template data is hard-wired
>      in proclang.c --- this should be replaced later by a new shared
>      system catalog, but we don't want to force initdb during 8.1 beta.
>      This change lets us cleanly load existing dump files even if they
>      contain outright wrong information about a PL's support functions, such
>      as a wrong path to the shared library or a missing validator function.
>      Also, we can revert the recent kluges to make pg_dump dump PL support
>      functions that are stored in pg_catalog.  While at it, I removed the
>      code in pg_regress that replaced $libdir with a hardcoded path for
>      temporary installations.  This is no longer needed given our support
>      for relocatable installations.
> This moved the helper functions into pg_catalog, but the author probably
> didn't realize that public schema helper functions would continue to be
> dumped by pg_dump.  These helper functions continued to be
> dumped/restored until the rename.  There are certainly helper functions
> for other languages that are still duplicated in the public schema ---
> there is nothing unique about plpython.  We are only seeing problems
> because of the rename.

Yes, I had the same layout for plpgsql. Already got rid of the public entry.

> In normal use, a pg_dumpall restore would throw an error about a missing
> helper function shared objects, but the pg_catalog entry would continue
> to work just fine.  Odd we have not heard complaints from users seeing
> that error on restore --- odds are, they are just ignoring the error,
> which pg_upgrade does not do.
> The attached pg_upgrade patch adds checks for this plpython helper
> function and reports a proper error, suggesting how to fix the problem:
> 	Performing Consistency Checks
> 	-----------------------------
> 	Checking current, bin, and data directories                 ok
> 	Checking cluster versions                                   ok
> 	The old cluster has a "plpython_call_handler" function defined
> 	in the "public" schema which is a duplicate of the one defined
> 	in the "pg_catalog" schema.  You can confirm this by executing
> 	in psql:
> 	        \df *.plpython_call_handler
> 	The "public" schema version of this function was created by a
> 	pre-8.1 install of plpython, and must be removed for pg_upgrade
> 	to complete because it references a now-obsolete "plpython"
> 	shared object file.  You can remove the "public" schema version
> 	of this function by running the following command:
> 	        DROP FUNCTION public.plpython_call_handler()
> 	in each affected database:
> 	        test
> 	        test3
> 	Remove the problem functions from the old cluster to continue.
> 	Failure, exiting


> We could do the same for other PL languages if they are ever renamed.  I
> suppose we don't care about fixing the duplicate schema entries.

Not sure what duplicate entries you are referring to. The two pg_catalog 
entries refer to different handlers, the call handler and the inline 


Adrian Klaver

In response to


pgsql-bugs by date

Next:From: Bruce MomjianDate: 2012-05-30 02:34:16
Subject: Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
Previous:From: Craig RingerDate: 2012-05-30 01:08:07
Subject: Re: BUG #6663: 64bit *conn not handled properly by PQfinish

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group