[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

Stephen Frost sfrost at snowman.net
Wed Aug 30 05:29:23 PDT 2017


* Sandro Santilli (strk at kbt.io) wrote:
> On Wed, Aug 30, 2017 at 01:19:03AM -0400, Stephen Frost wrote:
> 
> > That is, if you have 9.4 + 2.2 and 9.5 + 2.3, pg_upgrade will refuse to
> > run because it's looking in the 9.5 version for the 2.2 .so file and not
> > finding it.  Users have to first upgrade to 9.4 + 2.3 and then run
> > pg_upgrade to get to 9.5 + 2.3.
> 
> But pg_upgrade makes NO ATTEMPT at every running an ALTER EXTENSION,
> correct ? That means that *even* if you have a 2.2 .so file under 9.5 
> you might still be left with half-broken PostGIS (ie: scripts not
> using 9.5 only features).

pg_upgrade doesn't run anything in the new cluster which could change
the on-disk contents, nor will it ever because that would remove the
option for people to roll back to the old cluster (assuming they're
using link mode).

I'm a bit surprised, and rather concerned, to hear that an upgrade of
9.4 to 9.5 when 2.3 is installed in both leads to a 'half broken' state
of PostGIS.  The alternative approach would be to install 2.2 on 9.5,
then upgrade, and then upgrade PostGIS on 9.5 to 2.3, presumably that
would be correct?  Is there actually anything which would actively break
if the upgrade is done in the other way?

> That's why I'm suggesting that pg_upgrade could improve its checking
> (since it does implement part of it).

What checking would it do, exactly?  I'm sure we'd be open to adding
additional checks into pg_upgrade to ensure a successful upgrade.

> Or allow dropping the initial check (as I think you can still run
> ALTER EXTENSION UPDATE while missing the old .so file, right?)

This would depend on exactly what the extension and the
ALTER EXTENSION UPDATE script does.  Consider if a table installed by
PostGIS (similar to spatial_ref_sys) contained a geometry column.

I'm not sure that people would really see a successful pg_upgrade being
returned but not having a resulting functional system until an
ALTER EXTENSION UPDATE is done as really being a step forward either,
even if it could be guaranteed to work.

Thanks!

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170830/df522fba/attachment.sig>


More information about the postgis-devel mailing list