pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17144: Upgrade from v13 to v14 with the cube extension failed
2+ messages / 2 participants
[nested] [flat]
* BUG #17144: Upgrade from v13 to v14 with the cube extension failed
@ 2021-08-15 17:23 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2021-08-15 17:23 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: a.kozhemyakin@postgrespro.ru
The following bug has been logged on the website:
Bug reference: 17144
Logged by: alex kozhemyakin
Email address: a.kozhemyakin@postgrespro.ru
PostgreSQL version: 14beta1
Operating system: ubuntu 20.04
Description:
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"
The reproducing script:
PGBIN_OLD=/home/test/rel13
PGBIN_NEW=/home/test/rel14
PGDATA_OLD=/home/test/data_old
PGDATA_NEW=/home/test/data_new
git clone https://github.com/postgres/postgres.git postgres &&
cd ./postgres &&
git checkout REL_13_STABLE && git reset --hard HEAD && git rebase
./configure --prefix=$PGBIN_OLD
make -j2 > /dev/null && make -j2 -C contrib > /dev/null &&.
make install > /dev/null && make install -C contrib > /dev/null &&
git checkout REL_14_STABLE && rm -rf * && git reset --hard HEAD && git
rebase
./configure --prefix=$PGBIN_NEW
make -j2 > /dev/null && make -j2 -C contrib > /dev/null &&.
make install > /dev/null && make install -C contrib > /dev/null &&
cd ..
$PGBIN_OLD/bin/initdb -D $PGDATA_OLD &&.
$PGBIN_OLD/bin/pg_ctl -w -D $PGDATA_OLD -l logfile_old start &&
$PGBIN_OLD/bin/psql -c 'create extension earthdistance cascade;' postgres
&&
$PGBIN_OLD/bin/pg_ctl -w -D $PGDATA_OLD stop &&
$PGBIN_NEW/bin/initdb -D $PGDATA_NEW &&.
$PGBIN_NEW/bin/pg_upgrade -b $PGBIN_OLD/bin -d $PGDATA_OLD -B $PGBIN_NEW/bin
-D $PGDATA_NEW &&
$PGBIN_NEW/bin/pg_ctl -w -D $PGDATA_NEW -l logfile_new start &&
$PGBIN_NEW/bin/psql -f ./update_extensions.sql postgres
Removing the earthdistance extension in PG 13 before the upgrade resolves
the issue.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed
@ 2021-08-16 16:05 Tom Lane <tgl@sss.pgh.pa.us>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2021-08-16 16:05 UTC (permalink / raw)
To: a.kozhemyakin@postgrespro.ru; +Cc: pgsql-bugs@lists.postgresql.org
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 than via 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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2021-08-16 16:05 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-08-15 17:23 BUG #17144: Upgrade from v13 to v14 with the cube extension failed PG Bug reporting form <noreply@postgresql.org>
2021-08-16 16:05 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox