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

Re: BUG #6532: pg_upgrade fails on Python stored procedures

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: stuart(at)stuartbishop(dot)net
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6532: pg_upgrade fails on Python stored procedures
Date: 2012-03-15 22:08:50
Message-ID: 20120315220850.GA20113@momjian.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Thu, Mar 15, 2012 at 01:13:29PM +0000, stuart(at)stuartbishop(dot)net wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      6532
> Logged by:          Stuart Bishop
> Email address:      stuart(at)stuartbishop(dot)net
> PostgreSQL version: 9.1.3
> Operating system:   Ubuntu
> Description:        
> 
> The 9.1.3 changelog states pg_upgrade's handing of plpython stored
> procedures was fixed, but that does not appear to be the case:

The change in 9.1.3 was to allow the pg_upgrade code which checks if all
the shared librarires are in place to see plpython.so as equivalent to
plpython2.so.  I did not modify pg_dump at all, which is where you are
seeing the error.

> There were problems executing "/usr/lib/postgresql/9.1/bin/psql" --set
> ON_ERROR_STOP=on --no-psqlrc --port 5435 --username "postgres" -f
> "/var/lib/postgresql/pg_upgrade_dump_db.sql" --dbname template1 >>
> "/dev/null"
> Failure, exiting
> 
> 
> The relevant section of pg_upgrade_dump_db.sql is:
> 
> CREATE FUNCTION plpython_call_handler() RETURNS language_handler
>     LANGUAGE c
>     AS '$libdir/plpython', 'plpython_call_handler';

OK, I am pretty confused by this. 

Here is all I get in the pg_dumpall --binary-upgrade output for
plpython when I create one plpython function:

	--
	-- Name: plpythonu; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: postgres
	--
	
	CREATE OR REPLACE PROCEDURAL LANGUAGE plpythonu;
	
	
	ALTER PROCEDURAL LANGUAGE plpythonu OWNER TO postgres;
	
	SET search_path = public, pg_catalog;
	
	--
	-- Name: pymax(integer, integer); Type: FUNCTION; Schema: public; Owner: postgres
	--
	
	CREATE FUNCTION pymax(a integer, b integer) RETURNS integer
	    LANGUAGE plpythonu
	    AS $$
	         if a > b:
	           return a
	         return b
	     $$;
	
	
	ALTER FUNCTION public.pymax(a integer, b integer) OWNER TO postgres;

I have repeatedly upgraded from 9.0.X to 9.1.3 and am seeing no
failures.  The big question is what are you doing that is causing the
plpython_call_handler() function to be dumped?  That is an internal
function.  What is your old PG version?  I tested 8.4 and also could not
get the failure you see either.

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

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

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2012-03-15 22:13:45
Subject: Re: foreign key locks, 2nd attempt
Previous:From: Dimitri FontaineDate: 2012-03-15 22:06:09
Subject: Re: Command Triggers, v16

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2012-03-15 22:13:51
Subject: Re: BUG #6511: calling spi_exec_query from non-main package, results in: couldn't fetch $_TD
Previous:From: barry_bellDate: 2012-03-15 19:04:58
Subject: BUG #6534: Passing numeric Bind variables to ODBC driver convers to"Double precision"

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