Search Postgresql Archives

Re: pg_upgrade from 12 to 13 failes with plpython2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 18, 2020 at 10:06:17PM +0000, Devrim Gunduz wrote:
> Hi,
> 
> On Wed, 2020-11-18 at 14:54 -0500, Tom Lane wrote:
> > Uh-huh, so there you have it.  These must be leftovers from some
> > pre-extension incarnation of plpython that was never cleaned up
> > properly. 
> 
> I think this was broken when Marcin first dropped the language. We
> should just have dropped the extension, I guess.

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@xxxxxxxxxx>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux