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
