Re: pg_upgrade from 12 to 13 failes with plpython2

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: pg_upgrade from 12 to 13 failes with plpython2
Дата
Msg-id 97B34E7D-9A94-413E-8A04-D9C3683EE2AC@gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade from 12 to 13 failes with plpython2  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: pg_upgrade from 12 to 13 failes with plpython2  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-general


> On Nov 18, 2020, at 9:39 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Wed, Nov 18, 2020 at 09:35:20PM -0700, Rob Sargent wrote:
>>> pg_upgrade does have some code to handle plpython call handlers in
>>> function.c:get_loadable_libraries();
>>>
>>>        * Systems that install plpython before 8.1 have
>>>        * plpython_call_handler() defined in the "public" schema, causing
>>>        * pg_dump 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
>>>
>>> --
>>> Bruce Momjian  <bruce@momjian.us>        https://momjian.us
>>> EnterpriseDB                             https://enterprisedb.com
>>>
>>> The usefulness of a cup is in its emptiness, Bruce Lee
>>>
>>>
>> Unless it stop at prompts for “Yes, ok, I understand.” this could easily fly out the window.
>
> It issues this message and fails:
>
>            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_fatal("Remove the problem functions from the old cluster to continue.\n");
>
>
Does this jive with OP’s experience?  Or should it?


В списке pgsql-general по дате отправления:

Предыдущее
От: 江川潔
Дата:
Сообщение: CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade from 12 to 13 failes with plpython2