Re: pg_upgrade from 12 to 13 failes with plpython2

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Devrim Gündüz <devrim(at)gunduz(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marcin Giedz <marcin(dot)giedz(at)arise(dot)pl>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Magnus Hagander <magnus(at)hagander(dot)net>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade from 12 to 13 failes with plpython2
Date: 2020-11-19 05:57:00
Message-ID: 97B34E7D-9A94-413E-8A04-D9C3683EE2AC@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> On Nov 18, 2020, at 9:39 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2020-11-19 05:57:38 Re: pg_upgrade from 12 to 13 failes with plpython2
Previous Message 江川潔 2020-11-19 04:43:07 CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall