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

Regina Obe lr at pcorp.us
Wed Aug 30 13:52:26 PDT 2017


Well I'm pretty sure any old library will not do.  I've tried that.

 

pg_upgrade I think at least checks to see if it can load the main hook function using the new PostgreSQL.  That's why copying the old 2.3 .so from a PostgreSQL 9.6 instance to 10.0 doesn't work.

 

However I haven't checked to see if making a dummy extension would pass pg_upgrade's test.

 

So perhaps you can create a postgresql extension called  -- dummy with nothing in it.

 

And then have  postgis-2.3  be a symlink to dummy.

 

I suspect that won't work though.  Because I do recall a time I think it was between 2.0 and 2.1 when we made a function change and I tried to do my usual hack of copying the new 2.1 and calling it 2.0 so I could pg_upgrade

And it hiccupped when it couldn't load the function.  That function however might have been a key one that gets called as part of our load process though.  I can't remember what it was exactly.

 

 

 

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Darafei "Kom?pa" Praliaskouski
Sent: Wednesday, August 30, 2017 5:22 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

 

I think we need someone to set up experiment, if it is possible to symlink just any library before update, or if it should really match. If it's not called in upgrade and stuff like autovacuum/autoanalyze/whatever uses postgis functions silently are shut down, it may happen that just presence of a shim is enough.

Looking at linux .../lib directories, it's common for liblibrary-1.2.3 to have a symlink from liblibrary-1.2 and from liblibrary-1 and from liblibrary.so. It may also be a way to deal with it.

 

ср, 30 авг. 2017 г. в 11:48, Sandro Santilli <strk at kbt.io <mailto:strk at kbt.io> >:

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).

That's why I'm suggesting that pg_upgrade could improve its checking
(since it does implement part of it).
Or allow dropping the initial check (as I think you can still run
ALTER EXTENSION UPDATE while missing the old .so file, right?)

--strk;
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170830/d79cd33f/attachment.html>


More information about the postgis-devel mailing list