Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does everyone run ancient Postgres versions?

neon.tech

Post reply on HN
Print view View original

411–420 of 452 posts

Re: Why does everyone run ancient Postgres versions?

#411

Post by stickfigure »

evanelias wrote: post #364
stickfigure wrote: post #362

Earlier quoted context omitted.

"Aside from missing his head, the patient appears to be in fine shape."

That hardly seems equivalent. Why do you need to e.g. reconfigure replication inside of a transaction in the first place? The lack of transactional DDL is a totally valid complaint, but the non-DDL stuff is just a total head-scratcher to me. Aside from DDL, implicit commits have literally never impacted me in my 21 years of using MySQL.

Sorry - I was trying to make light of the discussion. DDL is so important that it's silly to talk about the other stuff.

Re: Why does everyone run ancient Postgres versions?

#412

Post by lazide »

ktosobcy wrote: post #278
noirscape wrote: post #156

Because 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…

This! I already mentioned this a while back and was basically berated (by someone that seemed like a dev/close to dev) that current setup is just fine and because of postgress complexity (extensions) it has to be done that way... and while I like postgress a lot it's quite annoying that the upgrade is such a terrible experience... :|

I suspect it’s also a bit of stockhold syndrome on behalf of admins haha

Re: Why does everyone run ancient Postgres versions?

#413

Post by daleswanson »

thomaslord wrote: post #282
noirscape wrote: post #156

Because 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…

I'll confess - I have a project that uses Heroku's managed Postgres and my preferred upgrade method is to set the maintenance window to the middle of the night, create a backup, and be awake at 1am to make sure that nothing is broken after they force the upgrade. Their auto-upgrade process hasn't failed me so far, but there's no way to manually trigger it.

What do you mean? You can manually run Heroku database maintenance. We just did this recently at work.

https://devcenter.heroku.com/articles/heroku-postgres-mainte...

Re: Why does everyone run ancient Postgres versions?

#414

Post by ComputerGuru »

evanelias wrote: post #321
ttfkam wrote: post #299

Earlier quoted context omitted.

> none of them could articulate what part of its feature set they actually needed to use. Transactional DDL: migration errors never leave the database in an intermediate/inconsistent state. Range types + exclusion constraint: just no way to do this in MySQL without introducing a race condition. Writeable CTEs: creating insert/update/delete pipelines over multiple tables deterministically. Seriously though, the RETURN…

That's a good list [1]. A handful of these are already doable in modern MySQL and/or MariaDB though. JSON can often be used in place of arrays, and JSON_TABLE in both MySQL and MariaDB converts JSON into tabular data. MySQL supports multi-valued indexes over JSON, where each row can have multiple index entries (or no entries, e.g. partial index). MariaDB has built-in convenience types for ipv4, ipv6, and uuid. Or in…

You still can’t use uuid as proper foreign keys with validation on mariaDB/MySQL though, right? It wasn’t possible with blobs at any rate.

Re: Why does everyone run ancient Postgres versions?

#415

Post by The_Colonel »

bastawhiz wrote: post #359
The_Colonel wrote: post #111

Earlier quoted context omitted.

> it can be stored safely in 2704 No, it can't. URL doesn't have any length limit, regardless of the fact that different software will impose different limits.

Browser address bars have a limit of 2048, so if that's your use case, yes it's safe.

Safari has 80 000, Firefox 65K.

There are plenty of needs to store URLs which will never go through a browser.

You can only claim that "some URL use cases" can be stored in 2048 characters.

Re: Why does everyone run ancient Postgres versions?

#416

Post by ktosobcy »

lazide wrote: post #412
ktosobcy wrote: post #278

Earlier quoted context omitted.

This! I already mentioned this a while back and was basically berated (by someone that seemed like a dev/close to dev) that current setup is just fine and because of postgress complexity (extensions) it has to be done that way... and while I like postgress a lot it's quite annoying that the upgrade is such a terrible experience... :|

I suspect it’s also a bit of stockhold syndrome on behalf of admins haha

Or better yet - "guarding the job", i.e. making their job very important ;)

Re: Why does everyone run ancient Postgres versions?

#417

Post by anticensor »

cenamus wrote: post #118
paulryanrogers wrote: post #2

Upgrades are hard. There was no replication in the before times. The original block-level replication didn't work among different major versions. Slony was a painful workaround based on triggers that amplified writes. Newer PostgreSQL versions are better. Yet still not quite as robust or easy as MySQL. At a certain scale even MySQL upgrades can be painful. At least when you cannot spare more than a few minutes of dow…

Is slony some sort of language joke? Slon is czech (probably slavic in general) for elephant. (which may be actually derived from the turkish aslan, for lion, but somehow the animal got mixed up)

Not really, the older form of Turkish aslan is actually arslan.

Re: Why does everyone run ancient Postgres versions?

#418

Post by lazide »

ktosobcy wrote: post #416
lazide wrote: post #412

Earlier quoted context omitted.

I suspect it’s also a bit of stockhold syndrome on behalf of admins haha

Or better yet - "guarding the job", i.e. making their job very important ;)

Very true. At a prior company, we rolled out a simpler and easier to use admin console for our enterprise product and all the customer admins hated it.

Because now it was easy to use hah.

We ended up rolling it back because the hate was so consistent.

(And no, this wasn’t us guessing or making this up - a number of them were quite explicit that we were threatening their roles, and to stop it.)

Re: Why does everyone run ancient Postgres versions?

#419

Post by MaKey »

thrdbndndn wrote: post #410
MaKey wrote: post #395

Earlier quoted context omitted.

He also says: > Your best bet is to yry 7z to uncompress the zip file with AES encrypted entries. So why not just do that and call it a day?

Because this does not only happen to unzip and I want to find a solution in general.

What do you mean exactly with "this"? The upstream unzip doesn't support AES_WG. How should a general solution look like?

Re: Why does everyone run ancient Postgres versions?

#420

Post by sudhirj »

homebrewer wrote: post #204
sudhirj wrote: post #142

Earlier quoted context omitted.

Is this process materially different from a vacuum? Does it manage to optimise without a write lock?

http://rhaas.blogspot.com/2011/02/mysql-vs-postgresql-part-2...

That helps a lot thanks. Will summarize it quickly for those who come later: MySQL (InnoDB really) and Postgres both use MVCC, so they write a new row on update. InnoDB however also additionally writes a record marking the old row for deletion.

To do a cleanup, InnoDB uses the records it kept to delete old data, while Postgres must do a scan. So InnoDB pays a record-keeping price as part of the update that makes it easier to clear data, while Postgres decides to pay this price of occasional scanning.

Post reply on HN