From: Bruce Momjian Date: Fri, 1 Jun 2012 15:40:04 +0000 (-0400) Subject: In pg_upgrade, report pre-PG 8.1 plpython helper functions left in the X-Git-Tag: REL9_2_BETA3~137 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8fcbfea7885f53b5a16610f7f03c276df49ef3d4;p=postgresql In pg_upgrade, report pre-PG 8.1 plpython helper functions left in the public schema that no longer point to valid shared object libraries, and suggest a solution. --- diff --git a/contrib/pg_upgrade/function.c b/contrib/pg_upgrade/function.c index 90e8a9f581..b4b17badb2 100644 --- a/contrib/pg_upgrade/function.c +++ b/contrib/pg_upgrade/function.c @@ -132,7 +132,8 @@ get_loadable_libraries(void) PGresult **ress; int totaltups; int dbnum; - + bool found_public_plpython_handler = false; + ress = (PGresult **) pg_malloc(old_cluster.dbarr.ndbs * sizeof(PGresult *)); totaltups = 0; @@ -157,9 +158,67 @@ get_loadable_libraries(void) FirstNormalObjectId); totaltups += PQntuples(ress[dbnum]); + /* + * Systems that install plpython before 8.1 have + * plpython_call_handler() defined in the "public" schema, causing + * pg_dumpall to dump it. However that function still references + * "plpython" (no "2"), so it throws an error on restore. This code + * checks for the problem function, reports affected databases to the + * user and explains how to remove them. + * 8.1 git commit: e0dedd0559f005d60c69c9772163e69c204bac69 + * http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php + * http://archives.postgresql.org/pgsql-bugs/2012-05/msg00206.php + */ + if (GET_MAJOR_VERSION(old_cluster.major_version) < 901) + { + PGresult *res; + + res = executeQueryOrDie(conn, + "SELECT 1 " + "FROM pg_catalog.pg_proc JOIN pg_namespace " + " ON pronamespace = pg_namespace.oid " + "WHERE proname = 'plpython_call_handler' AND " + "nspname = 'public' AND " + "prolang = 13 /* C */ AND " + "probin = '$libdir/plpython' AND " + "pg_proc.oid >= %u;", + FirstNormalObjectId); + if (PQntuples(res) > 0) + { + if (!found_public_plpython_handler) + { + pg_log(PG_WARNING, + "\nThe old cluster has a \"plpython_call_handler\" function defined\n" + "in the \"public\" schema which is a duplicate of the one defined\n" + "in the \"pg_catalog\" schema. You can confirm this by executing\n" + "in psql:\n" + "\n" + " \\df *.plpython_call_handler\n" + "\n" + "The \"public\" schema version of this function was created by a\n" + "pre-8.1 install of plpython, and must be removed for pg_upgrade\n" + "to complete because it references a now-obsolete \"plpython\"\n" + "shared object file. You can remove the \"public\" schema version\n" + "of this function by running the following command:\n" + "\n" + " DROP FUNCTION public.plpython_call_handler()\n" + "\n" + "in each affected database:\n" + "\n"); + } + pg_log(PG_WARNING, " %s\n", active_db->db_name); + found_public_plpython_handler = true; + } + PQclear(res); + } + PQfinish(conn); } + if (found_public_plpython_handler) + pg_log(PG_FATAL, + "Remove the problem functions from the old cluster to continue.\n"); + totaltups++; /* reserve for pg_upgrade_support */ /* Allocate what's certainly enough space */ @@ -245,12 +304,6 @@ check_loadable_libraries(void) * For this case, we could check pg_pltemplate, but that only works * for languages, and does not help with function shared objects, * so we just do a general fix. - * - * Some systems have plpython_call_handler() that references - * "plpython" defined in the "public" schema, causing pg_dump to - * dump it an generate an error on pg_dumpall restore; not sure - * on the cause, see: - * http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php */ if (GET_MAJOR_VERSION(old_cluster.major_version) < 901 && strcmp(lib, "$libdir/plpython") == 0)