←back to thread

Why does everyone run ancient Postgres versions?

(neon.tech)
264 points davidgomes | 5 comments | 17 Oct 24 21:23 UTC | HN request time: 0.221s | source
Show context
elric ◴[18 Oct 24 06:25 UTC] No.41876822[source]▶
Lots of dogmatism in this discussion, it seems. A couple of things:

1. Most psql deployments are not exposed to the interwebz, they are typically only accessible to the applications that need them by virtue of network setup (firewalls etc). This limits the attack vector to whatever the application does. Good.

2. Distro vendors (RHEL et al) often stick to major psql release for the lifecycle of the OS version. If the OS lives longer than the psql major version, they take on the responsability of backporting critical security issues.

3. While upgrades aren't hard, they're not easy either.

4. Psql is pretty much feature complete for many workloads, and pretty stable in general. For many people, there is little need to chase the latest major version.

replies(7): >>41876901 #>>41877104 #>>41877174 #>>41877411 #>>41877438 #>>41878003 #>>41879089 #
atoav ◴[18 Oct 24 07:29 UTC] No.41877104[source]▶
Also:

5. If your IT department is spread thin already and that old version is running fine, the incentive to potentially create more work for yourself is not gigantic.

replies(1): >>41877167 #
Dalewyn ◴[18 Oct 24 07:42 UTC] No.41877167[source]▶
One of the first laws of the universe that a good engineer learns is: Do not fix what is not broken.

And no, being old is not broken.

replies(9): >>41877567 #>>41877619 #>>41877848 #>>41877998 #>>41878067 #>>41878190 #>>41879176 #>>41880524 #>>41880526 #
1. WJW ◴[18 Oct 24 10:36 UTC] No.41878067[source]▶
The entire field of maintenance engineering would like a word. Over longer periods of time it's vastly cheaper to regularly fix things even before they break, and software is no exception.

Amongst other reasons:

- Performing regular upgrades is an easy and cheap way to maintain a healthy knowledge base about the system. It's always easier to fix a system that is well understood than a black box which nobody has touched in 20 years. Upgrading regularly also leads to people being more comfortable with the upgrade process and it is likely to become a "regular thing" with checklists and other process improvements that make maintenance safer and more reliable.

- Doing preemptive maintenance means YOU get to choose when the system is unavailable and then you can plan accordingly, perhaps by planning it during a period with low usage or even arranging for a redundant system to take up the load. The alternative is leaving it up to chance when a system will fail, and that's frequently at high-load moments when you can least afford it.

- As a corollary to the previous point: a team which is in control of its systems can have more predictable output of feature work, since there will be fewer "unexpected" events.

Not maintaining your systems is only cheaper in the long run if you don't count the engineering time required to fix things when they break or need to be replaced. Ounce of prevention vs pound of cure and all that.

replies(4): >>41878215 #>>41879543 #>>41879999 #>>41881886 #
2. LaGrange ◴[18 Oct 24 10:59 UTC] No.41878215[source]▶
> The entire field of maintenance engineering would like a word. Over longer periods of time it's vastly cheaper to regularly fix things even before they break, and software is no exception.

I mean I think it's because maintenance is so unglamorous. So when it happens and everything doesn't collapse, nobody remembers and starts asking why we even do it (and then sysadmins and middle management suddenly aren't a thing, and companies and IT become exactly as fragile as anyone with _actual_ understanding of management would expect).

Meanwhile when regular maintenance fails in progress, it often ends up in the news with a body count attached.

One of my favourite podcasts has a running joke that you should never do maintenance (because so many industrial disasters happen during it). Of course the bias is the point of the joke - and usually the reason things went bad is because either the maintenance was neglected until that point, or the engineering picked Postgresql, I mean, didn't consider the necessity of maintenance.

3. caeril ◴[18 Oct 24 13:59 UTC] No.41879543[source]▶
Not to mention:

- If you're scared to perform upgrades, this is a good indicator that you lack confidence in your backup/recovery/reversion policies and procedures, probably for good reason, so maybe fix that.

4. diffeomorphism ◴[18 Oct 24 14:53 UTC] No.41879999[source]▶
Maintenance engineering is in full agreement with that. You are maintaining the old version, backporting fixes etc. instead of tearing down the whole thing and replacing it with new shiny all the time.
5. elric ◴[18 Oct 24 18:01 UTC] No.41881886[source]▶
> The entire field of maintenance engineering would like a word. Over longer periods of time it's vastly cheaper to regularly fix things even before they break, and software is no exception.

and

> Not maintaining your systems is only cheaper in the long run if you don't count the engineering time required to fix things when they break or need to be replaced. Ounce of prevention vs pound of cure and all that.

Those are pithy assertions, but I don't think they're universally factually correct. This applies at some scales, but not at others. One size does not fit all, nor does one maintenance strategy fit all. I do believe I specifically called out the dogmatism in this discussion, and yet here we go piling on more of the same. I don't think that's terribly helpful. I assume that everyone is well aware of all the points you raised, as I suspect that most people running PostgreSQL are not in fact incompetent.

Not everyone has a team which "is in control of its systems", nor can everyone afford such a team. It may well be cheaper for some people to run something old until it burns only to have The Database Consultant come in one day to raise it from the dead.