News for hackers. Stuff that matters.
Re:Why Does Everyone Run Ancient Postgres Versions? by forinti on Friday October 18, 2024 @08:14AM (#41878670)
I have always compiled from source so that I can have more than one version in place. The installation takes less than 1GB and is quite easy and fast to compile and I've never had any issues with upgrades. If you forget to compile an extension, you can do it later, copy the .so to the right folder, and you don't even have to restart the cluster.

If you don't want to use pg_upgrade, you can dump from one cluster and pipe directly into another, with no need for a temporary file. It couldn't be easier.

Can't say the same for Oracle. Even applying a patch can ruin several weekends.

Re:Why Does Everyone Run Ancient Postgres Versions? by literalAardvark on Friday October 18, 2024 @08:45AM (#41878915)
> It couldn't be easier

If you have a trivial database, yes.

If you have a large, complicated database that takes hours/days to restore and has an HA SLA, very hell no.

Re:Why Does Everyone Run Ancient Postgres Versions? by forinti on Friday October 18, 2024 @09:23AM (#41879224)
That's not going to be easy with any database.
Re:Why Does Everyone Run Ancient Postgres Versions? by Too on Friday October 18, 2024 @10:02AM (#41879571)
With mongodb in a HA setup you can perform a staggered upgrade of individual nodes in the cluster with no downtime. Very smooth in my experience.
Re:Why Does Everyone Run Ancient Postgres Versions? by water9 on Saturday October 19, 2024 @07:12AM (#41887158)
Yeah, but what is your dataset is partitioned horizontally? It’s very smooth until it’s not. For example, if you are using the postGIS extensions and something changes with the new version that could be a showstopper
Re:Why Does Everyone Run Ancient Postgres Versions? by danudey on Friday October 18, 2024 @01:28PM (#41881588)
MySQL, for all its faults, actually handles this quite well. Generally speaking, assuming there aren't any major backwards-incompatibilities (which there haven't often been in my experience), you can start up the old server in place of the new server and you're good to go. Some table-rebuilding can be done in-place if you need to do things like recreate indices, but _generally_ you're good to go from there.

For more complex deployments, cases of backwards-incompatibilities in the data structure, or where I had reason to rebuild many large tables, you set up a replication secondary, do pre-upgrade migrations (e.g. in the case of deprecated functionality), upgrade the secondary, do post-upgrade migrations (e.g. in the case of new functionality), and wait for replication to catch up 100%. Then, after sending traffic to it for a bit to ensure it works correctly, you swap the primary and secondary and do it again.

Re:Why Does Everyone Run Ancient Postgres Versions? by magicalhippo on Saturday October 19, 2024 @08:28AM (#41887428)
We have customers with not quite TB levels, but at least several hundreds GB databases.

Upgrading the database server is as simple as shutting down the service, installing new executables and restarting the service. Downtime is measured in minutes.

When upgrading major versions, one might not get full functionality of the new features unless one upgrades the on-disk format (unload-reload), but you can run the new server version with older on-disk format just fine.

Re:Why Does Everyone Run Ancient Postgres Versions? by icedchai on Friday October 18, 2024 @11:39AM (#41880421)
I worked at a place that was running a 8 year old install of Oracle 8i because upgrading was just too painful. Oracle 10g was out by that point. It's been over 15 years since... I wonder if they ever upgraded?