Re: Pg13 upgrade issues?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Pg13 upgrade issues?

rmrodriguez
I think Sandro had some PR proposal to address the upgrade issue but I think it needed some more work and review. I haven't spent any time looking at the issue myself and right now my plate is pretty full, so on one hand I'm inclined to ask people to upgrade to 3.0 *before* upgrading to PG13, but on the other hand the upgrade process is painful enough to put more spokes in the wheels.



On Thu, Sep 10, 2020 at 5:50 PM Paul Ramsey <[hidden email]> wrote:
I'm taking this from chat to email because chat isn't very durable.

As far as I can tell, we have outstanding Pg13 issues [1], demonstrable just by running

   make installcheck

At a minimum, the run_test.pl script in --extension --upgrade mode will tests upgrades from 'unpackaged', which are now unavailable in Pg13. So that test needs to be lopped out or version flagged.

More maximally, I am unsure what our situation is for 2.X->3.X upgrades, since we were dependent on using the unpackaged source version to bundle up the postgis_raster extension. Are we still? Is this something with a fix planned, or is the fix to tell people "don't do that" and direct them through an upgrade chain of 12/2->12/3->13/3?

I just confirmed that I can build, install and enable 2.5 under Pg13, so an upgrade path via 12/3 could be a problem going forward.

    POSTGIS="2.5.5dev r17978" [EXTENSION] PGSQL="130" GEOS="3.9.0-CAPI-1.14.0"

Any information about current state of upgrade versus Pg13?

Thanks,
P

_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel


--
Raúl Marín Rodríguez
carto.com

_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pg13 upgrade issues?

Regina Obe

Because the postgis_extensions_upgrade() takes no arguments.

 

It reads the latest version from postgis.config  postgis-raster.config.

 

I suspect you installed 3.1 first and then 2.5 after.  So 2.5 is considered the default.

 

From: postgis-devel [mailto:[hidden email]] On Behalf Of Paul Ramsey
Sent: Thursday, September 10, 2020 12:31 PM
To: PostGIS Development Discussion <[hidden email]>
Subject: Re: [postgis-devel] Pg13 upgrade issues?

 

 

Further to this, since it's possible to install 2.5 on Pg13, I thought I'd check to see what a naive upgrade would look like, and it's this:

 

postgis25=# alter extension postgis update to '3.1.0dev';
WARNING:  unpackaging raster
WARNING:  PostGIS Raster functionality has been unpackaged
HINT:  type `SELECT postgis_extensions_upgrade();` to finish the upgrade. After upgrading, if you want to drop raster, run: DROP EXTENSION postgis_raster;
ALTER EXTENSION
postgis25=# SELECT postgis_extensions_upgrade();
NOTICE:  Updating extension postgis from 3.1.0dev to 2.5.5dev
ERROR:  extension "postgis" has no update path from version "3.1.0dev" to version "2.5.5dev"
CONTEXT:  SQL statement "ALTER EXTENSION postgis UPDATE TO "2.5.5dev";"
PL/pgSQL function postgis_extensions_upgrade() line 68 at EXECUTE

 

Why the order of upgrade version gets flipped around in postgis_extensions_upgrade() is a bit of a mystery to me.


_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pg13 upgrade issues?

Sandro Santilli-4
On Tue, Sep 15, 2020 at 06:39:24PM +0200, [hidden email] wrote:
> I've been wondering about this and thought about another solution that I
> think is simpler: We could have postgis (core) drop any types and functions
> owned by it that now belong to postgis_raster.
>
> The main benefit would be that it will work no matter the PG release or the
> source Postgis release. The drawbacks: any dependency on raster (views and
> so on) will need to be dropped in this process (only once) and that you
> need to install postgis_raster if you use raster (beforehand the functions
> were already there).

And actual data ! Sounds very drastic, why would this be simpler than
packaging on 'CREATE EXTENSION' ?

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pg13 upgrade issues?

Paul Ramsey


> On Sep 15, 2020, at 9:53 AM, Sandro Santilli <[hidden email]> wrote:
>
> On Tue, Sep 15, 2020 at 06:39:24PM +0200, [hidden email] wrote:
>> I've been wondering about this and thought about another solution that I
>> think is simpler: We could have postgis (core) drop any types and functions
>> owned by it that now belong to postgis_raster.
>>
>> The main benefit would be that it will work no matter the PG release or the
>> source Postgis release. The drawbacks: any dependency on raster (views and
>> so on) will need to be dropped in this process (only once) and that you
>> need to install postgis_raster if you use raster (beforehand the functions
>> were already there).
>
> And actual data ! Sounds very drastic, why would this be simpler than
> packaging on 'CREATE EXTENSION' ?

Are you proposing direct editing the pg_extension and pg_depend tables to package the existing functions?
We still have the limitation that we cannot create an extension within another create extension, if I'm not mistaken?
I tried your PR, and the core idea of a fake 'unpackaged' target seems miraculously to work, so there's just some polish to be added to the PR as far as I can tell. What do you feel are the drawbacks of it? The further we get away from 2.X, the less the "hackiness" of the solution matters in practical terms.

P

_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pg13 upgrade issues?

Sandro Santilli-4
On Tue, Sep 15, 2020 at 09:56:40AM -0700, Paul Ramsey wrote:
> > On Sep 15, 2020, at 9:53 AM, Sandro Santilli <[hidden email]> wrote:
> >
> > And actual data ! Sounds very drastic, why would this be simpler than
> > packaging on 'CREATE EXTENSION' ?
>
> Are you proposing direct editing the pg_extension and pg_depend tables to package the existing functions?

Nope. I'm proposing that postgis--3.1.0.sql includes the
code of postgis--unpackaged--3.1.0.sql under a conditional
(postgis already exists), so that we package any existing
one.

> We still have the limitation that we cannot create an extension within another create extension, if I'm not mistaken?

No mistake, we'd just have postgis_extensions_upgrade.sql run
the `CREATE EXTENSION postgis_raster` command without the `FROM
unpackaged` suffix.

> I tried your PR, and the core idea of a fake 'unpackaged' target seems miraculously to work, so there's just some polish to be added to the PR as far as I can tell. What do you feel are the drawbacks of it? The further we get away from 2.X, the less the "hackiness" of the solution matters in practical terms.

I don't see drawbacks other than the "hackish" mode.
If you like that model, we can as well go for it.
If not else, it's ready...

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: Pg13 upgrade issues?

rmrodriguez
On Tuesday, September 15, 2020, Sandro Santilli <[hidden email]> wrote:

And actual data ! Sounds very drastic, why would this be simpler than
packaging on 'CREATE EXTENSION' ?

Oops, I didn't realize it would drop data too. Please forget I said anything.



--
Raúl Marín Rodríguez
carto.com

_______________________________________________
postgis-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/postgis-devel