[postgis-users] Newest PostGIS code with old PostgreSQL major versions

Paul Ramsey pramsey at cleverelephant.ca
Thu Aug 19 17:55:26 PDT 2021

Thanks for writing!

> On Aug 19, 2021, at 5:40 PM, Jeremy Schneider <schnjere at amazon.com> wrote:
> Hello,
> I would like to learn more about how the PostGIS development community thinks about old major versions of PostgreSQL.
> Specifically, I'm curious to hear a little more elaboration on this part of the PostGIS policy:
>> We may on occasion introduce compile support for a newer PostgreSQL major version in the previous micro version to allow easier PostgreSQL pg_upgrade migrations. ... While the PostGIS version may work on lower versions of PostgreSQL, GEOS, GDAL, and Proj, enhanced features may be disabled on the lower versions.
> https://postgis.net/eol_policy/
> I also notice that the support matrix says:
>> As a general rule, the PostGIS Project Steering committee tries to maintain support of PostGIS for at least two versions of PostgreSQL.
> https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS
> I see that PostGIS maintains stable branches for a number of years. I can't quite tell, but the statements above read to me like the latest versions of PostGIS aren't really tested with old versions of PostgreSQL. It sounds like you introduce compiler support for the purpose of upgrades, but the PostGIS development community doesn't spend much effort looking at PostGIS 3.1 on PostgreSQL 10 (for example) - beyond making sure it compiles successfully.

As new versions of PostGIS come out, they are added to our CI fleet, which includes lots of old PgSQL versions. They are not only compiled against old PgSQL but the full regression suite is run against them too. Insofar as our test coverage is comprehensive, there's nothing worse about old-PgSQL-new-PostGIS than new-PgSQL-new-PostGIS. 

That said, there *is* a practical real-world gap, which is that 
(a) most users (with real world work loads) encounter PostGIS via packaged builds
(b) most packagers build latest-PgSQL-latest-PostGIS and sometimes latest-PgSQL-second-latest-PostGIS for upgrade purposes
so effectively there's not a lot of real-world banging of old-PgSQL-new-PostGIS to drive "many eyeballs" bug discovery.

That said, I find it hard to think up any example of a bug that manifested on old-PgSQL only. Almost always bug reports are novel things based on new code / changes in the latest PostGIS version, not crazy version interaction things. Or they are really obscure things that have been around forever and tool someone twiddling exactly the right knob in exactly the right way 10 years after it was coded to produce something anomolous (like what I'm working on fixing now).

> If I'm reading this right, then when a heavy PostgreSQL v10 user loads the latest PostGIS code across wide fleets of PostgreSQL v10 systems, then they should expect to be on the cutting edge of that configuration, and they would likely be the first reporters of issues unique to running the latest PostGIS release on old PostgreSQL code.
> It might be "safer" for them to stick with PostGIS 2.4 stable releases on their PostgreSQL 10 fleet, and upgrade PostGIS around the same time as when they upgrade to the latest major version of PostgreSQL? (Which should happen within the next year, since PG 10 only has about a year of official lifetime remaining, similar to PostGIS 2.4.)
> But maybe I'm reading too much into this policy and the maintenance of stable branches, and maybe the PostGIS community would encourage everyone to run the latest available PostGIS major version even on very old versions of PostgreSQL? Also, the actual risk of issues     with running recent PostGIS code against really old PostgreSQL versions might not be that high in practice.

I think in general you are perhaps over-reading into the policy or imagining the implications of cross-version issues. In general the extension API has been stable/static for so long that changes to PgSQL just don't affect us a lot, at least at a functional "how things work" level.


> I'm a bit out of my depth here, and I'm looking for thoughts from folks who know a bit more about this than me.  :)
> Thanks,
> Jeremy
> -- 
> Jeremy Schneider
> Database Engineer
> Amazon Web Services
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users

More information about the postgis-users mailing list