Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#4717 closed defect (wontfix)

upgrading to 3.0.1 from 2.4.4 following docu does not work: "Updating extension postgis from 3.0.1 to 2.4.4" ?!

Reported by: tpo Owned by: pramsey
Priority: medium Milestone: PostGIS 3.0.2
Component: postgis Version: 3.0.x
Keywords: Cc:

Description

According to http://postgis.net/docs/manual-3.0/postgis_installation.html#soft_upgrade_extensions

One should upgrade like this:

ALTER EXTENSION postgis UPDATE TO "3.0.2dev";
ALTER EXTENSION postgis_topology UPDATE TO "3.0.2dev";

I am upgrading to 3.0.1 because there do not seem to exist higher version of postgis than postgresql-11-postgis-3 3.0.1+dfsg-2.pgdg100+1 for Debian buster at https://apt.postgresql.org.

If I do the above then I get:

psql > ALTER EXTENSION postgis UPDATE TO "3.0.1"; ALTER EXTENSION postgis_topology UPDATE TO "3.0.1";
WARNING:  unpackaging raster
WARNING:  PostGIS Raster functionality has been unpackaged
HINT:  type `SELECT postgis_extensions_upgrade(); to finish the upgrade. After upgrading, if you want to drop raster, run: DROP EXTENSION postgis_raster;

Let's see where we're at:

psql > \dx
                                        List of installed extensions
       Name       | Version |   Schema   |                             Description                             
------------------+---------+------------+---------------------------------------------------------------------
 hstore           | 1.4     | public     | data type for storing sets of (key, value) pairs
 plpgsql          | 1.0     | pg_catalog | PL/pgSQL procedural language
 postgis          | 3.0.1   | public     | PostGIS geometry, geography, and raster spatial types and functions
 postgis_topology | 3.0.1   | topology   | PostGIS topology spatial types and functions
(4 rows)

So let us now update, as indicated by the "hint" above:

psql> SELECT postgis_extensions_upgrade();
NOTICE:  Updating extension postgis from 3.0.1 to 2.4.4
ERROR:  extension "postgis" has no update path from version "3.0.1" to version "2.4.4"
CONTEXT:  SQL statement "ALTER EXTENSION postgis UPDATE TO "2.4.4";"
PL/pgSQL function postgis_extensions_upgrade() line 68 at EXECUTE

So I'd say there's something broken there.

Change History (6)

comment:1 by strk, 4 years ago

NOTICE: Updating extension postgis from 3.0.1 to 2.4.4

What's broken is that your operating system thinks 2.4.4 is the "default postgis" to be installed (postgis.control in $(pg_config --sharedir)/extensions/)

Surely postgis_extensions_upgrade() could handle this case and avoid even *trying* to "upgrade" from newer to older version, but the underlying problem remains: you seem to have installed 2.4.4 *after* 3.0.1. Re-installing 3.0.1 should fix this problem.

comment:2 by tpo, 4 years ago

Thanks a lot @strk for your reply.

I've reinstalled both the postgresql-10-postgis-3 and postgresql-10-postgis-3-scripts packages but the result is exactly the same.

(Note for other people reading this ticket: it's $(pg_config --sharedir)/extension/ without the trailing 's' (i.e. /usr/share/postgresql/10/extension/).

Which one would be the file that the "operating system" thinks is the "default postgis"? Is it this one:

/usr/share/postgresql/10/extension/postgis.control

Note that the packet manager tells me that that file only exists in:

dpkg -S /usr/share/postgresql/10/extension/postgis.control
postgresql-10-postgis-2.4-scripts: /usr/share/postgresql/10/extension/postgis.control

No such file exists inside the postgresql-10-postgis-3-scripts package.

How does the "operating system" determine, which the "default postgis" would be?

?

Last edited 4 years ago by tpo (previous) (diff)

comment:3 by robe, 4 years ago

Resolution: wontfix
Status: newclosed

This is a user issue and not a postgis issue so marking as won't fix.

comment:4 by robe, 4 years ago

as noted in irc, that fact there is no postgis-3-scripts postgis.control file sounds like a packaging mistake.

I would try editing the postgresql-10-postgis-2.4-scripts/postgis.control

and change the 2.4.4 to 3.0.1 and then try finishing your upgrade.

comment:5 by robe, 4 years ago

From irc

11:39:22	ReginaObe[m]:	ah but you said no such file exists in the postgresql-10-postgis-3-scripts one -- hmm that sounds like a packaging mistake
11:39:39	tpo2:	I do not know how one can figure that out - with $(pg_config --sharedir)/extension/ that would be /usr/share/postgresql/11/extension/postgis.control, however that's for pg 11 and I'm upgrading from pg 10 -> pg 11 so I need the pg 10 control file and that would be /usr/share/postgresql/10/extension/postgis.control which comes from the postgresql-10-postgis-2.4-scripts package
11:40:14	Algunenano:	Wait, are you updating both things at the same time?
11:40:26	ReginaObe[m]:	at anyrate if you can edit the postgresql-10-postgis-2.4-script/postgis.control and change the version on it from 2.4.4 to 3.0.1 that should allow you to upgrade
11:40:53	tpo2:	ReginaObe[m], I can remove /usr/share/postgresql/10/extension/postgis.control and instead symlink that file to /usr/share/postgresql/10/extension/postgis-3.control
11:41:48	ReginaObe[m]:	ah that's where they put it
11:41:48	tpo2:	ReginaObe[m], OK, thanks a lot - however that will only fix it hackishly for me and everybody else will need to hack around it as well...
11:41:51	ReginaObe[m]:	yap do that
11:42:26	ReginaObe[m]:	I thought they were supposed to provide a toggle for that according to Myon - ping Myon
11:42:42	tpo2:	Algunenano, I'm first upgrading postgis 2.4.4 -> 3.0.1 in postgres-10 then pg_dumping that and the pg_restore'ing that into postgres-11
11:43:22	tpo2:	ReginaObe[m], thanks a lot (really!) I'll ping Myon
11:43:25	Algunenano:	tpo2: If you are going to dump anyway you don't need to do the upgrade. Just install postgis (and postgis_raster) in the new database and load the 2.4 dump

comment:6 by tpo, 4 years ago

@robe wrote:

This is a user issue and not a postgis issue so marking as won't fix.

and later:

as noted in irc, that fact there is no postgis-3-scripts postgis.control file sounds like a packaging mistake.

If both of these assertions should be true at the same time, then that would mean that the packaging mistake is a user issue and won't be fixed. Right?

Note: See TracTickets for help on using tickets.