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
|
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: