Centos side of things. This isn't laziness on the part of the maintainers, rather there's so much in the way of advances that it's simply not practical to maintain this technical debt for longer than a few years at a time. Best practices require the same versioned extension to be present on both source and target data clusters. Keep in mind when it comes to major version differences some extensions are more flexible than others. Otherwise, one is forced to remove it from the source data cluster if it's not present on the target. For some extensions, such as the internal ones that come bundled with the PostgreSQL packages and certain 3rd party extensions, such as pg_repack, it is possible to upgrade between extension major versions without issue. In regards to PostGIS: when faced with different extension versions between the source and target data clusters one must begin by upgrading postgis on the source data cluster such that it matches BOTH the major and minor versions of the target data cluster and only thereafter performing the PostgreSQL upgrade. Alternatively, one can install a downgraded major/minor version of PostGIS on the target data cluster, matching the source data cluster's major and minor version of PostGIS, and then upgrade PostgreSQL (yes, this is convoluted). Some cloud providers do NOT offer more than one version of PostGIS for any particular version of PostgreSQL thereby making the previous recommendation redundant. The reason is simple, they are not prepared to handle PostGIS upgrades. There are ways of dealing with them but that's for another blog. Please note that this is a rapidly moving target and can/will probably change in the future. Because the PostgreSQL community repository removes all versions of PostgreSQL and their extensions when they have reached end-of-life. PostGIS package support becomes problematic when upgrading database servers that have reached end-of-life. Over the past twenty years, I've had occasion to upgrade some fairly large installations using PostGIS, the most complex being over 120TB data on a version of PostgreSQL that hadn't been upgraded in several years and the PostGIS was so old that it wasn't even installed using extensions. As a result of this and other experiences I have, where possible, adopted the practice of performing PostGIS and PostgreSQL upgrades as separate exercises. I can't emphasize enough that regression testing for each GIS function call be made thoroughly in a development environment before going into production. Because the PostGIS project's development cycle advances at the same torrid pace as the demand for GIS, it can happen that the intrinsic behavior of a function can change seemingly without warning. Therefore, merely validating the API via a document review is insufficient, i.e. TEST IT! Here's a tip: Turn on run-time parameter track_functions and you'll be able to identify all those wonderful PostGIS functions your application stack depends upon. Finally, by all means, take a look at an earlier blog "Working with PostgreSQL and PostGIS: How To Become A GIS Expert" for more information about PostGIS." loading="lazy" style="display: block; margin-bottom: 5px; clear:both;max-width: 100%;" link_thumbnail="" srcset="https://www.percona.com/blog/wp-content/uploads/2021/11/Issues-Upgrading-PostGIS-and-PostgreSQL-200x105.png 200w, https://www.percona.com/blog/wp-content/uploads/2021/11/Issues-Upgrading-PostGIS-and-PostgreSQL-300x157.png 300w, https://www.percona.com/blog/wp-content/uploads/2021/11/Issues-Upgrading-PostGIS-and-PostgreSQL-1024x536.png 1024w, https://www.percona.com/blog/wp-content/uploads/2021/11/Issues-Upgrading-PostGIS-and-PostgreSQL-1140x595.png 1140w, https://www.percona.com/blog/wp-content/uploads/2021/11/Issues-Upgrading-PostGIS-and-PostgreSQL-367x192.png 367w, https://www.percona.com/blog/wp-content/uploads/2021/11/Issues-Upgrading-PostGIS-and-PostgreSQL.png 1200w" sizes="(max-width: 200px) 100vw, 200px" />PostGIS is arguably the best GIS implementation in the world. There may be other database technologies with GIS but the value proposition of quality, performance, and sophistication, and, of course, cost, is nowhere near what PostgreSQL offers. So let me set the stage for this blog of mine: youve been using PostGIS on your PostgreSQL [&]

https://www.percona.com/blog/issues-upgrading-postgis-and-postgresql/