Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1mFf7i-0002D0-LI
	for pgsql-bugs@arkaria.postgresql.org; Mon, 16 Aug 2021 16:06:02 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1mFf7g-0005qa-BT
	for pgsql-bugs@arkaria.postgresql.org; Mon, 16 Aug 2021 16:06:00 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1mFf7g-0005qS-4e
	for pgsql-bugs@lists.postgresql.org; Mon, 16 Aug 2021 16:06:00 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1mFf7b-00034B-3D
	for pgsql-bugs@lists.postgresql.org; Mon, 16 Aug 2021 16:05:59 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 17GG5rNe895153;
	Mon, 16 Aug 2021 12:05:53 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: a.kozhemyakin@postgrespro.ru
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17144: Upgrade from v13 to v14 with the cube extension
 failed
In-reply-to: <17144-e67d7a8f049de9af@postgresql.org>
References: <17144-e67d7a8f049de9af@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 15 Aug 2021 17:23:58 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <895151.1629129953.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Aug 2021 12:05:53 -0400
Message-ID: <895152.1629129953@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/895152.1629129953%40sss.pgh.pa.us>
Precedence: bulk

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 o=
f
> extension "earthdistance"

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

regression=3D# CREATE EXTENSION cube VERSION '1.4';
CREATE EXTENSION
regression=3D# CREATE EXTENSION earthdistance;
CREATE EXTENSION
regression=3D# 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 =3D cube_recv, SEND =3D cube_send );

with stack trace

#0  errfinish (filename=3D0x9c15e3 "pg_depend.c", lineno=3D210, =

    funcname=3D0x9c1660 <__func__.16045> "recordDependencyOnCurrentExtensi=
on")
    at elog.c:515
#1  0x000000000049886f in recordDependencyOnCurrentExtension (
    object=3Dobject@entry=3D0x7ffe09f2b778, isReplace=3DisReplace@entry=3D=
true)
    at pg_depend.c:206
#2  0x00000000005f65ce in GenerateTypeDependencies (
    typeTuple=3DtypeTuple@entry=3D0x2fa8f70, =

    typeCatalog=3DtypeCatalog@entry=3D0x7fc882ee5970, =

    defaultExpr=3DdefaultExpr@entry=3D0x0, typacl=3Dtypacl@entry=3D0x0, =

    relationKind=3DrelationKind@entry=3D0 '\000', =

    isImplicitArray=3DisImplicitArray@entry=3Dfalse, isDependentType=3Dfal=
se, =

    rebuild=3Dtrue) at pg_type.c:614
#3  0x000000000069519e in AlterTypeRecurse (typeOid=3D37834, =

    isImplicitArray=3D<optimized out>, tup=3D<optimized out>, =

    catalog=3D0x7fc882ee5970, atparams=3D0x7ffe09f2bba0) at typecmds.c:441=
1
#4  0x0000000000695265 in AlterTypeRecurse (typeOid=3D37745, =

    isImplicitArray=3D<optimized out>, tup=3D<optimized out>, =

    catalog=3D0x7fc882ee5970, atparams=3D0x7ffe09f2bba0) at typecmds.c:448=
8
#5  0x00000000006997f6 in AlterType (stmt=3Dstmt@entry=3D0x2fb01f0)
    at typecmds.c:4313
#6  0x00000000008340be in ProcessUtilitySlow (pstate=3D0x2ee2900, =

    pstmt=3D0x2ee2b88, =

    queryString=3D0x2f067b8 "/* contrib/cube/cube--1.4--1.5.sql */\n\n-- c=
omplain if script is sourced in psql, rather than via ALTER EXTENSION\n\n\=
n-- Remove @ and ~\nDROP OPERATOR @ (cube, cube);\nDROP OPERATOR ~ (cube, =
cube);\n\n-- Add"..., context=3DPROCESS_UTILITY_QUERY, params=3D0x0, query=
Env=3D0x0, qc=3D0x0, =


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 =3D {classId =3D 1247, objectId =3D 37834, objectSubId =3D 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