[postgis-devel] liblwgeom symbols exported by postgis module

[Paragon Corporation]

> If someone goes from 2.1.8 to 2.1.9, _prior_ to run the scripts upgrade
procedure (ALTER EXTENSION or sourcing postgis_upgrade.sql) she'll have the
old scripts served by the new "postgis-2.1.so"
> library, which would contain the new "liblwgeom-2.1.9.a" symbols.

> If liblwgeom was linked dynamically, in the above scenario she'll have the
old scripts served by the new "postgis-2.1.so" library, which would
dynamically link to the new "liblwgeom.so.2.1.9"

> I'm not sure if this confirms your assumptions.

Well not quite.  I'm thinking future. Let's suppose someone is running
PostGIS 2.2.0 (liblwgeom-2.dll)  and later they upgrade to PostGIS 2.3.0

I want to make sure the PostGIS 2.2.0 is not fed by liblwgeom... distributed
by PostGIS 2.3.0  because that would introduce possibly breaking changes or
enhancements the user does not want.


>> It's a shame Debian provides only one single postgis version, as that 
>> makes it very difficult for people to do a pg_upgrade.  If they were 
>> to go to PostgreSQL 9.5 from PostgreSQL 9.4, and you only provide a 
>> PostGIS 2.2 on
>> 9.5 (and not a 2.2 on PostgreSQL 9.4) or vice versa.  They can't just 
>> do the soft upgrade and pg_upgrade migrate or pg_upgrade  /soft postgis
upgrade.

> Didn't we recently fix that need for the old library being around ?

Yes, this is a different issue I am talking about.  

> Or do we have an open ticket describing the issue ?
I did not open a ticket because it's really up to the maintainers (or if
PostgreSQL changes how pg_upgrade works -- I think they are aware of the
issue upstream)
We as a project can't do anything about it.  

On windows I always try to provide the newest version of PostGIS for at
least one version of PostgreSQL behind the latest PostgreSQL offering.  This
is so people can use pg_upgrade to upgrade.   I think I once tried tricking
pg_upgrade by renaming the .so/.dll it was looking for and it failed and
even failed if we do a micro that changes an underlying function installed.

The issue is when pg_upgrade runs as part of its checking it does a check on
the lib dependencies of the functions (since its doing a file migration, the
create extension stuff doesn't get reinstalled.
If it comes across a function where it can't find the corresponding lib
entry, the whole upgrade fails.

 -  which is why I was very concerned when Paul introduced 
The KNN for postgresql 9.5 only that that feature doesn't affect the sql
installed).

So if you have say 2.1.8 on your 9.4, you can't upgrade to 9.5 2.2.0 UNLESS
you
a) do a dump restore -- a royal pain if you have databases larger than 200
GB.

b) Do a soft upgrade of your 9.4 to 2.2.0 and then hard  pg_upgrade to 9.5

or

c) Have 2.1.8 on 9.5, do  a pg_upgrade and then a soft upgrade to 2.2.0


It's a concern with people who have large databases where doing a dump /
restore is a monumental task

Also an issue for people with lots of databases.


Thanks,
Regina