From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | pgsql-pkg-yum(at)postgresql(dot)org, Devrim Gündüz <devrim(at)gunduz(dot)org> |
Cc: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
Subject: | Re: postgis for beta releases |
Date: | 2021-05-20 16:37:37 |
Message-ID: | 20210520163737.GA18818@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)cleverelephant(dot)ca>
> |Date: Fri Oct 4 18:25:46 2019 +0000
> | Restore ST_Union() aggregate signature and re-work...
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2021-05-20 19:36:02 | Re: postgis for beta releases |
Previous Message | Devrim Gündüz | 2021-05-19 23:21:09 | Re: Red Hat Enterprise Linux 8.4 upgrade uninstalls gdal32-libs and PostGIS |