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@xxxxxxxxxx> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
