Re: pg_upgrade from 12 to 13 failes with plpython2

On Wed, Nov 18, 2020 at 08:59:58PM +0100, Marcin Giedz wrote:
> 
> > anyway got this from your query:
> 
> > 16402 | plpython_call_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | f
> | f | v | u | 0 | 0 | 2280 | | | | | | | plpython_call_handler | $libdir/
> plpython2 | |
> > 16403 | plpython_inline_handler | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f |
> t | f | v | u | 1 | 0 | 2278 | 2281 | | | | | | plpython_inline_handler |
> $libdir/plpython2 | |
> > 16404 | plpython_validator | 11 | 10 | 13 | 1 | 0 | 0 | - | f | f | f | t | f
> | v | u | 1 | 0 | 2278 | 26 | | | | | | plpython_validator | $libdir/plpython2
> | |
> 
> Uh-huh, so there you have it.  These must be leftovers from some
> pre-extension incarnation of plpython that was never cleaned up
> properly.  Try
> 
> DROP FUNCTION pg_catalog.plpython_call_handler();
> DROP FUNCTION pg_catalog.plpython_inline_handler(internal);
> DROP FUNCTION pg_catalog.plpython_validator(oid);
> 
> It'll be interesting to see if there are any dependencies.
> 
>                         regards, tom lane
> 
> -------------------------------------
> 
> BINGO! after drops all went smooth and easy

I think one big problem is that when pg_upgrade fails in this way, users
are required to do some complex system catalog queries to diagnose the
cause.  Is there a way to simplify this for them?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

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