Re: postgis for beta releases - Mailing list pgsql-pkg-yum

From Justin Pryzby
Subject Re: postgis for beta releases
Date
Msg-id 20210520163737.GA18818@telsasoft.com
Whole thread Raw
In response to postgis for beta releases  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: postgis for beta releases  (Christoph Berg <myon@debian.org>)
List pgsql-pkg-yum
I'm suggesting to be build postgis31 for pg14.
It might be reasonable to wait for beta2, though.

Copying last year's correspondence for pg13.

On Fri, Jul 10, 2020 at 03:04:30PM -0500, Justin Pryzby wrote:
> Would you consider building packages during beta ?
> 
> This would allow us to do testing more easily, and I'm guessing that's true for
> other people too, which leads to wider field testing.

On Sat, Jul 11, 2020 at 11:46:20AM -0500, Justin Pryzby wrote:
> On Sat, Jul 11, 2020 at 05:09:12PM +0100, Devrim Gündüz wrote:
> > On Fri, 2020-07-10 at 15:04 -0500, Justin Pryzby wrote:
> > > Would you consider building packages during beta ?
> > 
> > You mean PostGIS 3.1? I thought I pushed it already :(
> 
> I think the postgis that exists for the stable release(12) should also be built
> for the beta release(13).  That allows test upgrades by 1) installing same
> postgis for new postgres; and 2) pg_upgrade.
> 
> Whether to build a new version of postgis is a separate question, but if you
> do, I'd suggest to build for both versions of postgres when possible.  That
> allows choice of which to upgrade first.
> 
> During beta period in previous years, postgis has been the one important thing
> missing.  That requires us to drop our postgis columns for beta testing.  Last
> year for the first time, I instead built postgis locally on a couple servers.
> 
> I think most packages aren't built for beta, which is no problem (although I
> think they sometimes needed to be added after the fact).  These are on our
> list: pg_repack, fincore, libpqxx-devel.
> 
> -- 
> Justin

On Tue, Jul 21, 2020 at 01:16:39PM -0500, Justin Pryzby wrote:
> On Sat, Jul 11, 2020 at 05:09:12PM +0100, Devrim Gündüz wrote:
> > 
> > Hi,
> > 
> > On Fri, 2020-07-10 at 15:04 -0500, Justin Pryzby wrote:
> > > Would you consider building packages during beta ?
> > 
> > You mean PostGIS 3.1? I thought I pushed it already :(
> > 
> > Built packages now. They will sync soon  to v13 testing repos. Would
> > you like me to build against v12 as well?
> 
> Thanks - I see that postgis31 is available for postgres13.
> 
> As I mentioned, I think postgis30 should *also* be built for v13, and postgis31
> should *maybe* be built for v12:
> 
> On Sat, Jul 11, 2020 at 11:46:20AM -0500, Justin Pryzby wrote:
> > I think the postgis that exists for the stable release(12) should also be built
> > for the beta release(13).  That allows test upgrades by 1) installing same
> > postgis for new postgres; and 2) pg_upgrade.
> > 
> > Whether to build a new version of postgis is a separate question, but if you
> > do, I'd suggest to build for both versions of postgres when possible.  That
> > allows choice of which to upgrade first.
> > 
> > During beta period in previous years, postgis has been the one important thing
> > missing.  That requires us to drop our postgis columns for beta testing.  Last
> > year for the first time, I instead built postgis locally on a couple servers.
> > 
> > I think most packages aren't built for beta, which is no problem (although I
> > think they sometimes needed to be added after the fact).  These are on our
> > list: pg_repack, fincore, libpqxx-devel.

On Sat, Sep 12, 2020 at 04:56:06PM -0500, Justin Pryzby wrote:
> On Tue, Jul 28, 2020 at 11:14:43AM +0100, Devrim Gündüz wrote:
> > On Tue, 2020-07-21 at 13:16 -0500, Justin Pryzby wrote:
> > > As I mentioned, I think postgis30 should *also* be built for v13, and
> > > postgis31 should *maybe* be built for v12:
> > 
> > Pushing them to v11 and v12 *testing* repos in an hour or so.
> 
> Note, I still suggest that postgis30 and postgis31 should *both* be built for
> postgres13 and (at least) postgres12.
> 
> I've done a couple test upgrades from pg12 to 13, some using pg_dump/restore,
> some using pg_upgrade.  In both cases, I first had to do:
> 
> |DROP AGGREGATE st_union(geometry);
> |DROP FUNCTION pgis_geometry_union_transfn;
> 
> I guess postgis30 and 31 are "compatible enough" that I was able to restore a
> postgis30 DB into a DB with only postgis31 available.
> 
> Normally, I'd have to do a "rolling upgrade", either:
> (pg12+gis30) => (pg12+gis31) => (pg13+gis31), or:
> (pg12+gis30) => (pg13+gis30) => (pg13+gis31).
> 
> I guess this is related to postgis commit 75a044c61:
> 
> |Author: Paul Ramsey <pramsey@cleverelephant.ca>
> |Date:   Fri Oct 4 18:25:46 2019 +0000
> |    Restore ST_Union() aggregate signature and re-work...



pgsql-pkg-yum by date:

Previous
From: Devrim Gündüz
Date:
Subject: Re: Red Hat Enterprise Linux 8.4 upgrade uninstalls gdal32-libs and PostGIS
Next
From: Christoph Berg
Date:
Subject: Re: postgis for beta releases