←back to thread

264 points davidgomes | 2 comments | | HN request time: 0s | source
Show context
elric ◴[] 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 #
newaccount74 ◴[] No.41877174[source]
> 3. While upgrades aren't hard, they're not easy either

I guess it depends on scale? I was surprised how easy it was on Ubuntu. There was an automatic migration script, and it worked. Took less than 5 minutes to upgrade.

Sure, there was downtime, but I think most applications out there can live with scheduled downtime of a few minutes.

If you can't have downtime, then nothing is easy.

replies(1): >>41877393 #
1. ForHackernews ◴[] No.41877393[source]
Lots of companies pretend like they can't afford 5 minutes of scheduled downtime. Then they end up with 12 hours of unscheduled downtime when shtf.
replies(1): >>41877558 #
2. bravetraveler ◴[] No.41877558[source]
For SRE (site reliability engineering) the term of art is 'error budget'

To others reading, be mindful: database upgrade times depend greatly on the data stored within them/where/who is using them. Your development environment doesn't represent production. If the distinction even exists!

A five minute upgrade can become indefinite with a single lock [row/table, depending on the storage engine/etc]