←back to thread

264 points davidgomes | 1 comments | | HN request time: 0.339s | source
Show context
buro9 ◴[] No.41877568[source]
Upgrading isn't automatic.

Let me check what I'm on... brb... Postgres 14.

Because it's not automatic I leave it, I leave it until it's so unsupported that I must upgrade the whole system, then I build a new system with a new Postgres and I migrate the old to the new.

I want, so badly, for Postgres to just automatically update itself, that a new binary just works with the data directory of an old version, and that if required it does an in-place upgrade to those data files when it can (i.e. if it can detect the last version was the same major as the current version, upgrade the files transparently to the admin).

My databases are all backed up each night, and these are single server Postgres with no replication or other trickery, an automatic upgrade for a single-server Postgres should be possible.

As it's not done... I assume (incorrectly?) that there be dragons and risks, and I mitigate that by never upgrading, just waiting and migrating. Migrating puts all of the risk on me, human error, and I am definitely fallible, so I can best handle this risk by just not doing it until I must.

Last migration I performed was from Postgres 7 > Postgres 14 in October 2021... I guess I have quite a few years of Postgres 14 ahead of me still. I would take downtime, my systems aren't zero downtime critical, just give me a super simple one-command no-questions upgrade as I really dislike migrations.

replies(5): >>41878044 #>>41878267 #>>41879156 #>>41880074 #>>41880604 #
1. Tostino ◴[] No.41880604[source]
I used to do the old pgdump for backups, but after using pgbackrest at work for years I see no reason not to use it for every cluster I want to back up.

I like pointing it at an S3 bucket so I have another full backup repo (with its own retention strategy) away from my homelab, as well as to my local NAS.