Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed

PG Bug reporting form <noreply@postgresql.org> writes:
> When trying to upgrade PostgreSQL 13 cluster with the earthdistance
> extension installed to PostgreSQL 14, I get the following error:
> psql:./update_extensions.sql:2: ERROR:  type earth is already a member of
> extension "earthdistance"

Hm, thanks.  This does not seem to be a problem with pg_upgrade per se;
you can reproduce it with

regression=# CREATE EXTENSION cube VERSION '1.4';
CREATE EXTENSION
regression=# CREATE EXTENSION earthdistance;
CREATE EXTENSION
regression=# ALTER EXTENSION "cube" UPDATE;
ERROR:  type earth is already a member of extension "earthdistance"

The failure happens during this command in cube--1.4--1.5.sql:

ALTER TYPE cube SET ( RECEIVE = cube_recv, SEND = cube_send );

with stack trace

#0  errfinish (filename=0x9c15e3 "pg_depend.c", lineno=210,
    funcname=0x9c1660 <__func__.16045> "recordDependencyOnCurrentExtension")
    at elog.c:515
#1  0x000000000049886f in recordDependencyOnCurrentExtension (
    object=object@entry=0x7ffe09f2b778, isReplace=isReplace@entry=true)
    at pg_depend.c:206
#2  0x00000000005f65ce in GenerateTypeDependencies (
    typeTuple=typeTuple@entry=0x2fa8f70,
    typeCatalog=typeCatalog@entry=0x7fc882ee5970,
    defaultExpr=defaultExpr@entry=0x0, typacl=typacl@entry=0x0,
    relationKind=relationKind@entry=0 '\000',
    isImplicitArray=isImplicitArray@entry=false, isDependentType=false,
    rebuild=true) at pg_type.c:614
#3  0x000000000069519e in AlterTypeRecurse (typeOid=37834,
    isImplicitArray=<optimized out>, tup=<optimized out>,
    catalog=0x7fc882ee5970, atparams=0x7ffe09f2bba0) at typecmds.c:4411
#4  0x0000000000695265 in AlterTypeRecurse (typeOid=37745,
    isImplicitArray=<optimized out>, tup=<optimized out>,
    catalog=0x7fc882ee5970, atparams=0x7ffe09f2bba0) at typecmds.c:4488
#5  0x00000000006997f6 in AlterType (stmt=stmt@entry=0x2fb01f0)
    at typecmds.c:4313
#6  0x00000000008340be in ProcessUtilitySlow (pstate=0x2ee2900,
    pstmt=0x2ee2b88,
    queryString=0x2f067b8 "/* contrib/cube/cube--1.4--1.5.sql */\n\n-- complain if script is sourced in psql, rather
thanvia ALTER EXTENSION\n\n\n-- Remove @ and ~\nDROP OPERATOR @ (cube, cube);\nDROP OPERATOR ~ (cube, cube);\n\n--
Add"...,context=PROCESS_UTILITY_QUERY, params=0x0, queryEnv=0x0, qc=0x0,  

So apparently the dependency-updating logic is a few bricks shy
of a load.  The object being passed to recordDependencyOnCurrentExtension
is

(gdb) p *object
$1 = {classId = 1247, objectId = 37834, objectSubId = 0}

which sure enough is type "earth".  So apparently, this code is
trying to absorb EVERYTHING that depends on type cube into the
cube extension.

[ experiments a bit more ]  It might just be directly-dependent types.
If I create a table column of type cube, then nothing strange happens
during the upgrade.  But if I create a domain over cube, then do the
update, the domain gets absorbed into the extension.  That'd be kind
of annoying :-(

Haven't discovered exactly where it's going off the rails, though.

            regards, tom lane