Live data from Hacker News

Jepsen: Amazon RDS for PostgreSQL 17.4

jepsen.io

21–30 of 153 posts

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#21

Earlier quoted context omitted.

I think zookeeper is still the only distributed system that got through jepsen without dataloss bugs, though at high cost: https://aphyr.com/posts/291-jepsen-zookeeper

Didn't FoundationDB get a clean bill of health?

wasn't tested because: "haven't tested foundation in part because their testing appears to be waaaay more rigorous than mine."

https://web.archive.org/web/20150312112552/http://blog.found...

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#22
post #5

This is in such a thick academic style that it is difficult to follow what the problem actually might be and how it would impact someone. This style of writing serves mostly to remind me that I am not a part of the world that writes like this, which makes me a little sad.

It uses a lot of very specific terminology, but the linked pages like the one on "G-nonadjacent" do a lot to clear up what it all means. It is a lot of reading.

Essentially: The configuration claims "Snapshot Isolation", which means every transaction looks like it operates on a consistent snapshot of the entire database at its starting timestamp. All transactions starting after a transaction commits will see the changes made by the transaction. Jepsen finds that the snapshot a transaction sees doesn't always contain everything that was committed before its starting timestamp. Transactions A an B can both commit their changes, then transactions C and D can start with C only seeing the change made by A and D only seeing the change made by B.

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#23
post #6
post #4

Earlier quoted context omitted.

Then you haven't read enough jepsen reports. Distributed system guarantees generally can't be trusted

Postgres is not a distributed system in this configuration usually though is it?

A multi-AZ cluster is necessarily a distributed system.

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#24
post #6

Earlier quoted context omitted.

Postgres is not a distributed system in this configuration usually though is it?

The result is for “Amazon RDS for PostgreSQL multi-AZ clusters” which are certainly a distributed system. I’m not well versed in RDS but I believe that clustered is the only way to use it.

An RDS cluster can have a single instance (but it can't be multi-AZ with a single instance.)

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#25
post #2

I thought this kind of bullshit was only supposed to happen in MongoDB!

Do people still use MongoDB in production? I was quite surprised to read that Stripe uses MongoDB in the early days and still today and I can't imagine the sheer nightmares they must have faced using it for all these years.

MongoDB is a very good database, and these days at scale I am significantly more confident in its correctness guarantees than any of the half-baked Postgres horizontal scaling solutions. I have run both databases at seven figure a month spend scale, and I would not choose off-the-shelf Postgres for this task again.

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#26
In my reading of this, it looks like the practical implication could be that reads happening quickly after writes to the same row(s) might return stale data. The write transaction gets marked as complete before all of the distributed layers of a multi AZ RDS instance have been fully updated, such that immediate reads from the same rows might return nothing (if the row does not exist yet) or older values if the columns have not been fully updated.

Due to the way PostgreSQL does snapshotting, I don't believe this implies such a read might obtain a nonsense value due to only a portion of the bytes in a multi-byte column type having been updated yet.

It seems like a race condition that becomes eventually consistent. Or did anyone read this as if the later transaction(s) of a "long fork" might never complete under normal circumstances?

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#27

Earlier quoted context omitted.

I think zookeeper is still the only distributed system that got through jepsen without dataloss bugs, though at high cost: https://aphyr.com/posts/291-jepsen-zookeeper

Didn't FoundationDB get a clean bill of health?

apparently wasn't tested because Kyle thought the internal testing was better than jepsen itself: https://abdullin.com/foundationdb-is-back/

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#28

Earlier quoted context omitted.

I think zookeeper is still the only distributed system that got through jepsen without dataloss bugs, though at high cost: https://aphyr.com/posts/291-jepsen-zookeeper

Didn't FoundationDB get a clean bill of health?

Aphyr didn’t test foundation himself, but the foundation team did their own Jepsen testing which they reported passing. All of this was a long time ago, before Foundation was bought by Apple and open sourced.

Now members of the original Foundation team have started Antithesis (https://antithesis.com/) to make it easier for other systems to adopt this sort of testing.

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#29
post #5

This is in such a thick academic style that it is difficult to follow what the problem actually might be and how it would impact someone. This style of writing serves mostly to remind me that I am not a part of the world that writes like this, which makes me a little sad.

[flagged]

posting this sort of LLM-generated garbage should get a ban.

have some respect for yourself and everyone else, christ.

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#30
post #5

This is in such a thick academic style that it is difficult to follow what the problem actually might be and how it would impact someone. This style of writing serves mostly to remind me that I am not a part of the world that writes like this, which makes me a little sad.

[flagged]

Posting ChatGPT outputs directly in a post with no attribution or indication that you are doing so is not helpful or authentic.
Post reply on HN