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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: BUG #6532: pg_upgrade fails on Python stored procedures
Дата
Msg-id 20120315220850.GA20113@momjian.us
обсуждение исходный текст
Ответ на BUG #6532: pg_upgrade fails on Python stored procedures  (stuart@stuartbishop.net)
Список 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 по дате отправления:

Предыдущее
От: vozhdb@gmail.com
Дата:
Сообщение: BUG #6533: postgre server crashes by create function (create table as)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #6511: calling spi_exec_query from non-main package, results in: couldn't fetch $_TD