Re: BUG #6532: pg_upgrade fails on Python stored procedures - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #6532: pg_upgrade fails on Python stored procedures
Date
Msg-id 20120315220850.GA20113@momjian.us
Whole thread Raw
In response to BUG #6532: pg_upgrade fails on Python stored procedures  (stuart@stuartbishop.net)
List pgsql-bugs
On Thu, Mar 15, 2012 at 01:13:29PM +0000, stuart@stuartbishop.net wrote:
> The following bug has been logged on the website:
>
> Bug reference:      6532
> Logged by:          Stuart Bishop
> Email address:      stuart@stuartbishop.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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

pgsql-bugs by date:

Previous
From: vozhdb@gmail.com
Date:
Subject: BUG #6533: postgre server crashes by create function (create table as)
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #6511: calling spi_exec_query from non-main package, results in: couldn't fetch $_TD