Jepsen: Amazon RDS for PostgreSQL 17.4 • Hacker News Board

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#151

Post by aphyr » Sat, May 03, 2025, 3:11 PM UTC

ants_a wrote: post #137

aphyr wrote: post #121

Earlier quoted context omitted.

Thank you matashii--this would definitely explain it. I've also received another email suggesting this anomaly is due to the difference in commit/visibility order between primary and secondary. Is there by chance a writeup of this available anywhere that I can link to? It looks like https://postgrespro.com/list/thread-id/1827129 miiight be related, but I'm not certain. If so, I'd like to update the report. My email i…

That thread is indeed about the same issue. I don't think anyone has done a more concise writeup on it. Core of the issue is that on the primary, commit inserts a WAL record, waits for durability, local and/or replicated, and then grabs a lock (ProcArrayLock) to mark itself as no longer running. Taking a snapshot takes that same lock and builds a list of running transactions. WAL insert and marking itself as visible…

Thanks to you both! I've updated the article to discuss this, and we've got an update on the AWS blog too. :-)

https://jepsen.io/analyses/amazon-rds-for-postgresql-17.4

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#152

Post by 0xCA1EB » Sun, May 04, 2025, 12:12 AM UTC

sgarland wrote: post #123

hliyan wrote: post #102

I wish more writing in the software world was done this way: "Amazon RDS for PostgreSQL is an Amazon Web Services (AWS) service which provides managed instances of the PostgreSQL database. We show that Amazon RDS for PostgreSQL multi-AZ clusters violate Snapshot Isolation, the strongest consistency model supported across all endpoints. Healthy clusters occasionally allow..." Direct, to-the-point, unembellished and an…

A company I was at had an internal blog where anyone could write an article, and others could comment on it. Zero requirement to do so, and it in no way factored into your rating. I think it was the result of a hackathon one year. Anyway, I really enjoyed it, because I like technical writing. I found that if I wrote a deeply technical post, I’d get very few likes and comments – in fact, I even had a Staff Eng tell me…

My favorite was "UUIDs as Primary Keys" (subheading: "Just Say No"). :)

It doesn't feel full of memes but it does have great illustrations! For example, this visualization of the fragmentation of data for a UUID v4 idb file:

https://cdn.zappy.app/b1b54bb0c780c0f6dd891475589aeee3.png

Re: Jepsen: Amazon RDS for PostgreSQL 17.4

#153

Post by derivagral » Sat, May 10, 2025, 9:49 PM UTC

shivasaxena wrote: post #139

havkom wrote: post #107

Good investigation! Software developers nowadays barely know about transactions, and definitely not about different transaction models (in my experience). I have even encountered "senior developers" (who are actually so called "CRUD developers"), who are clueless about database transactions.. In reality, transactions and transaction models matter a lot to performance and error free code (at least when you have volume…

This isn't confined just to senior developers. I have even encountered system architects who were clueless about Isolation levels. Some even confused "Consistency" in ACID with the "Consistency" in CAP. Makes me sad, since I work mostly in retail and and encounter systems that are infested with race conditions and simila errors: things where these isolation levels would be of great help. However it's mostly engineers…

Some time ago, this was important to decipher the marketing behind MongoDB. Their benchmarks ran with a loose isolation (read_uncommitted iirc) that didn't guarantee a durable flush, and they'd benchmark against defaults from postgres, etc, which didn't use this isolation.

Clearly it worked for them, but I spent a few different stints cleaning up after developers who didn't know this sort of thing.