#4170 closed defect (fixed)
ERROR: Upgrade of postgis from version 2.1.9 r15770 to version 3.0 requires a dump/reload. See PostGIS manual for instructions
| Reported by: | strk | Owned by: | strk |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 2.4.5 |
| Component: | build | Version: | master |
| Keywords: | Cc: | robe2 |
Description
Drone is currently failing because the upgrade test tries to do extension upgrade from 2.1.9 to 3.0 and the extension upgrade mechanism thinks such an upgrade is not possible between different major versions.
Change History (4)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
| Component: | postgis → build/upgrade/install |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
| Version: | 2.4.x → trunk |
comment:4 by , 6 years ago
I've basically hard-coded the fact that 2.x and 3.x are soft-upgrade-compatible…
Note:
See TracTickets
for help on using tickets.

The message comes from a check produced by utils/postgis_proc_upgrade.pl, specifically added to avoid incompatible upgrades:
IF old_maj != new_maj THEN RAISE EXCEPTION ''Upgrade of MODULE from version % to version % requires a dump/reload. See PostGIS manual for instructions'', old_scripts, new_scripts; ELSE RETURN ''Scripts versions checked for upgrade: ok''; END IF;Theoretically, that check should make loading postgis_ugrade.sql safe (doing nothing) when the target version is a major version higher than the source version of PostGIS, assuming a change in Major version will always only occur when the storage format changes, and thus assuming that changing input/output functions would in this case result in an unusable database.
As we changed Major version w/out such an occurrence we should ask ourselves whether we want to change semantic of Major version OR we want to differently determine if dump/reload is required in order NOT to brick someone's database…