Clock's ticking on PostgreSQL 12, but not everyone is ready to say goodbye Users of PostgreSQL 12 have less than a month to prepare for the database to enter end of life and become unsupported. Data from open source database support company Percona suggests that around 11 percent of PostgreSQL databases in the wild are still on version 12, first introduced in 2019. First developed in the 1980s, …
Does log shipping not count as incremental backup? What about streaming replication? Pretty sure real time recovery has been possible a couple of ways for a while… is this incremental restore from backup or just a shiny layer slapped on top of the pre existing features (very welcome, not saying it isn’t going to be useful!)
What is this new feature, hopefully there will be an El Reg article that answers these burning questions at some point. I miss the frequency of technical writing articles
About the only issue I had with PostgreSQL is the upgrade mechanism - across a major release, it's dump and restore, which involves downtime, and is a right pain.
Sure, there are ways to avoid it, but they're relatively advanced, and need to be set up before you start; they're not easy to retrofit.
If the project provided a built-in transparent upgrade path, I'm sure users would upgrade more readily.
It's somewhat sadder IMO. The project has a 1-command upgrade: install the new version side-by-side, run pg_upgradecluster {old version} {cluster} for each cluster in the local installation[1], bob's your uncle). However (at least on Debian/Ubuntu[2]), it won't be handled by the package manager if you used the default, ready-to-use cluster ("main") because it is automatically created on the new version and pg_upgradecluster refuses to overwrite a cluster on the newer version.
[1]: If using multiple clusters (groups of databases), you can upgrade at your leisure as long as you don't uninstall the old postgresql version
[2]: I run non-critical DBs (some downtime allowed) both using packaged from the official postgresql debian repo (at work for gitlab and other web apps that use postgresql as their backend, typically using the latest version) and the version from debian stable du jour (at home, for tt-rss). Always had that problem.
I think the simple answer is that this was never really considered core to the project (think of connections, replication, etc.) and, for those projects that required it, service providers are on-hand to help.
The dump and restore mechanism is rock solid and suitable for the vast majority of projects.
This - you are not wrong.
My background in MSSQL highlighted this..
In MSSQL, (for those that didn't know).generally you could detach the DB, then attach it to the newer version and stuff would just run pretty painlessly. It would default to the 'compatibility' of what it came from, and you might want to update statistics etc.
When I was lumbered with Postgres and needed to upgrade, it felt like I was pulled back 20 years.
Having worked with Postgres for the last twenty years (version 7 or 8), I remember the days when major releases were point releases. The switch to annual releases seems to imply that there are major changes between 12 and 17, but for most installs there aren't: there is some new stuff and some things got faster. Going between 8.2 and 9.0 probably involved more significant work.
The main driver behind time-based releases is to make changes more predictable and, therefore, more reliable. If you have an application running on a particular version of Postgres, you can probably expect to keep it running unchanged for many years to come, unless you want to use some of the newer features. But there are fairly good reasons for keeping up to date and, if you want to do so, you'll be looking for a clear roadmap so that you can plan development on test releases, for new functionality, and migration, usually to the previously shiny version.
I guess where people are likely to be caught out is where they have SaaS and get notices from the provider that particular versions will no longer be supported and they have work to do™
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
