[postgis-devel] PostGIS 3.3.0alpha1 released

Regina Obe lr at pcorp.us
Mon May 23 21:43:04 PDT 2022


> 3.3.0alpha1 built fine, NetBSD 9 amd64.
> 
> qgis is able to render OSM data from a postgis database, so things are
> >=99% ok.
> 
> I noticed that compared to 3.2.1 the sql scripts for 2.4.10 have gone
missing.
> 
[Regina Obe] 
My fault.  I guess I forgot to add 2.4.10 to the targets for 3.3.0.  Just
added at:
https://git.osgeo.org/gitea/postgis/postgis/commit/61402cf4dcd8a9e26199f0a0b
aa9b914c47f3f91

Speaking of which, pramsey, are you planning to do this in 3.3.0?

https://trac.osgeo.org/postgis/wiki/PostGISExtensionPaths

I think we settled on Solution 3 (my interpretation of what you meant, so
probably needs some rewording), but we can discuss in upcoming dev meeting.


> The tests are troubled, but I think in the same way I have been seeing for
a
> long time and have not managed to track down.
> 
> Looking at the release notes to understand soft/hard upgrade -- which I've
> never been clear on because until recently I've been in the "intending to
use
> postgis some day" category, I see that for 2.1.0 it exlains soft from 2.0+
and
> hard from earlier.  I don't see anything at all mentioned for 3.x, but
>
https://postgis.net/docs/manual-3.3/postgis_administration.html#upgrading
> says the release notes explain this.  So perhaps add
>   This release is a soft upgrade from >=2.0, and a hard upgrade from
earlier.
> if that's true (which would be a great situation).
[Regina Obe] 
Clarifications welcome.  Here is how it goes

< 2.0 requires hard upgrade.  This is because our on-disk format changed
majorly between 1.5 and 2.0
>= 2.0 is just soft upgrade. Even though we made some minor on-disk format,
we introduced a bit in 2.0, so the system knows if it is an old or new
format and updates, inserts etc, will slowly change data to new format.  So
old 2.0 and new 3.0 can coexist with no performance penalty (that is my
recollection)  


So from >= 2.0+  You can do:

ALTER EXTENSION postgis UPDATE;

For 2.5+ we introduced the 

SELECT postgis_extensions_upgrade();

Which upgrades all postgis extensions (postgis, postgis_raster,
postgis_topology, etc.) and can also convert a non-extension based postgis
to an extension one.

Even though we introduced this function in 2.5, our 3.0 unraveled the
postgis_raster from postgis extension, so the 2.5 postgis_extensions_upgrade
doesn't know about it and wouldn't upgrade properly . I think there were
some bugs too in the < 2.5.5 of that function that made it not usable in 3.0
upgrade. Again my recollection, strk correct me if I misspoke.

Thanks,
Regina









More information about the postgis-devel mailing list