Our team uses AWS managed postgres, and the ease of operations and upgrades really alleviates stress for us. Managed DBs are worth the cost.
Why does everyone run ancient Postgres versions?
141–150 of 452 posts
Re: Why does everyone run ancient Postgres versions?
#142Earlier quoted context omitted.
My experience has been exactly opposite. Ability to do Vacuums is good. MySQL doesn’t free up space taken by deleted rows. The only option to free up the space is to mysqldump the db and load it again. Not practical in most of the situations.
Not really, the innodb_file_per_table variable has been set to 1 for a long time. Running OPTIMIZE TABLE frees up the disk space in this case.
Is this process materially different from a vacuum? Does it manage to optimise without a write lock?
Re: Why does everyone run ancient Postgres versions?
#143I've used postgresql in most of my previous jobs, but using mariadb in my current one, and I must say it's a joy to administer. The replication and high availability that mariadb offers is rock solid, and much more advanced than what postgresql has to offer. It works out of the box, no plugins or third party shenanigans needed, and there is "one obvious way" to do it. Not a dozen options like in the postgresql ecosys…
[deleted]
Re: Why does everyone run ancient Postgres versions?
#144Earlier quoted context omitted.
I recall this being the case A LOOOONG time ago but I haven't heard of, read about, been warned to look out for or personally seen such a thing in forever. Have you? * I'm running a lot of MySQL stuff and such a topic might be of interest to me
From what I can tell, MySQL is supposed to be safe since 2018 if you have no data from before 2010. The fact that you still can't use DDL in transactions makes life exceedingly painful , but it's technically safe if you write your migration code carefully enough.
Some places still have columns declared as utf8 instead of utf8mb4, and there's a special place in hell for authors of the MySQL general clusterfuck regarding encodings - it was all nice and great if you didn't care about anything other than latin1 or ASCII - go outside that before utf8 option and it was horror that even experienced operators managed to fuckup (I have a badge from a Google conference in 2017 with nicely visible effect of "we have mixed up one of the three separate encoding settings in MySQL and now you have mojibake in your badge").
And then there's UTF8 not actually being UTF8, which can result in total lockup of a table if someone inputs a character that does not fit in UCS-2 and now you need to recover the database from backup and preferably convert all instances of utf8 to utf8mb4, because fuck you that's why.
Re: Why does everyone run ancient Postgres versions?
#145Earlier quoted context omitted.
"Not as robust as MySQL"? Surely you're joking.
It is hard to live down a reputation ;) MySQL was immortalized as the database in every LAMP stack. And just like PHP it improved considerably since then.
Also for licensing reasons for a long time there was surviving contingent of MySQL 3.23 in LAMP hosting.
Re: Why does everyone run ancient Postgres versions?
#146Because upgrading is a lot of work, and is higher risk than upgrading other software.
I find that upgrading Postgresql is really easy.
Testing all the apps that use it, not so much.
Re: Why does everyone run ancient Postgres versions?
#147I have a large production deployment that is still on 9.6 because the software depends on table inheritance. (Oh man!)
For a while I had a separate version 9 cluster because of one application.
But it wasn't really a nuisance. Postgresql doesn't give a DBA much to worry about.
Re: Why does everyone run ancient Postgres versions?
#148Re: Why does everyone run ancient Postgres versions?
#149My upgrade policy for everything: Significant security vulnerability? Upgrade Feature you need? Upgrade All other reasons: Don't upgrade. Upgrading takes effort and it is risky. The benefits must be worth the risks.
Upgrading when multiple versions behind is significantly more risky than doing it when the update is relatively fresh. Additionally, actions done frequently are less risky than actions done rarely, since you develop skills in performing that action as an organization - see high deployment frequency as a strategy of managing deployment risk. This adds up to continuous upgrading being the least risky option in aggregat…
Not if software regressions are the main concern.
Re: Why does everyone run ancient Postgres versions?
#150Lots 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…
> 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.
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.