Earlier quoted context omitted.
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.
One of the first laws of universe that an experienced engineer learns is that "do not fix what is not broken" never actually applies, and is only brought up by people invulnerable to consequences. That doesn't mean "upgrade recklessly," but it does mean you should know _why_ you're either upgrading or _NOT_ upgrading. That's your job, much more than the act of upgrading itself. Unpublished vulnerabilities in old soft…
Why does everyone run ancient Postgres versions?
301–310 of 452 posts
Re: Why does everyone run ancient Postgres versions?
#302Earlier quoted context omitted.
> 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.
That's not going to be easy with any database.
Re: Why does everyone run ancient Postgres versions?
#303Earlier quoted context omitted.
My opinion is Postgres was designed by software developers for software developers. The split on “which relational database to use” in my career has almost always been perfectly split between SWE vehemently demanding pgsql for the feature set, and the sysadmins having to support maintenance and production availability preferring MySQL. One of the few things I’ve enjoyed with the move into devops and companies forcing…
> The split on “which relational database to use” in my career has almost always been perfectly split between SWE vehemently demanding pgsql for the feature set I’ve seen this as well, but when pressed, none of them could articulate what part of its feature set they actually needed to use. > One of the few things I’ve enjoyed with the move into devops and companies forcing previously “pure” developers into operationa…
That's a true shame considering how easy it is to make a read replica of any size and then fail over to it as the new primary. Definite skill issues.
Re: Why does everyone run ancient Postgres versions?
#304Because the actual process of upgrading Postgres is terrible. I say this as someone who absolutely loves using it, but the actual process of upgrading Postgres is something that takes significant downtime, is error-prone and you're often better off just dumping all the databases and reimporting them in a new folder. (A good idea in general since it'll vacuum and compact indexes as well if you do it, combining a few m…
ADd to that: if it works, don't fix it.
I keep an eye out for vulnerabilities, and that's about it.
Re: Why does everyone run ancient Postgres versions?
#305Earlier quoted context omitted.
What is this holding back? A redo based alternative to MVCC?
Nope, that is totally unrated. To support upgrade in place without an old version of PostgreSQL: 1. The new version of PostgreSQL would need to able to read all old catalog table formats and migrate them. 2. The new version of PostgreSQL would need to support all old versions of the parse tree to migrate views. 3. Likely a bunch of more things that I do not know of. I for example doubt it is trivial to just read an o…
It works with basically no downtime but I agree this kind of thing should definitely be easier, even turnkey.
Re: Why does everyone run ancient Postgres versions?
#306Earlier quoted context omitted.
"What the application does" may not be what you think of, as it is dependent on how secure the application or the layers beneath it are. This is how people get everything pwned step by step. The database server may then reveal credentials to other apps etc.
If the database server has significant "other apps", which it probably doesn't.
Re: Why does everyone run ancient Postgres versions?
#307Earlier quoted context omitted.
To be fair to PostgreSQL, it has multiple replication setups because they have different inherent properties. For instance, it comes with built in streaming and logical replication setups. Which should you use? It’s impossible to say without knowing your own exact use case. By analogy: should a database cluster optimize consistency or availability? Answer: there’s no way its author can guess which is more important t…
MySQL/MariaDB have binary and logical replication too. They also support much more advanced topologies like multi-master out of the box. It's just that what you need for 99% of situations relies on a well trodden path and requires no configuration at all. I have suspected for a long time that most people who criticize MySQL have never actually worked with it, or have done so a couple of decades ago. It's often the de…
Re: Why does everyone run ancient Postgres versions?
#308Earlier quoted context omitted.
In 2012 MySQL had several flavors of replications, each with its own very serious pitfalls that could introduce corruption or loss of data. I saw enough of MySQL replication issues in those days that I wouldn't want to use it. But sure, it was easy to get a proof of concept working. But when you tried to break it by turning off network and/or machines, then shit broke down in very broken ways that was not recoverable…
Maybe that was true in 2012 (maybe it was related to MyISAM) but by ~2015 with InnoDB MySQL replication was rock solid.
How did you verify that it was rock solid? And which of the variants did you use?
Re: Why does everyone run ancient Postgres versions?
#309You might as well ask, why does anyone run an older version or anything? The reasons will be largely the same. Most of the software on my machines are "old" because they are part of a Linux distribution that (aside from security issues) was frozen in time a year or two ago so that it could be tested, released, and maintained. I am quite happy to have a system that I know is not going to break (either itself, or my wo…
Re: Why does everyone run ancient Postgres versions?
#310Lots 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…
Upgrading a datastore is a massive, massive risk. It requires a lot of work, planned downtime, or some way to smear updates across the estate. The cost of any failure is very high. The benefit of any major upgrade is also vanishingly small. Unless you need a specific feature, its just not worth it.
…or you're on AWS RDS, which will automatically bump your db cluster if it goes EOL and you ignore the notices for more than a year.