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 по дате отправления: