honestly this made me side-eye aws docs hard, i always think snapshot isolation just means what it says. good catch
Jepsen: Amazon RDS for PostgreSQL 17.4
91–100 of 153 posts
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#92It's not mentioned in the headline and not made super clear in the article: This is specific to multi-AZ clusters, which is a relatively new feature of RDS, and differ from multi-AZ instance that most will be familiar with. (Clear as mud.) Multi-AZ instances is a long-standing feature of RDS where the primary DB is synchronously replicated to a secondary DB in another AZ. On failure of the primary, RDS fails over to…
Have one question So if snapshot violation is happening inside Multi-AZ instances, it can happen with a single region - multiple read replica kind of setup as well ? But it might be easily observable in Multi-AZ setups because the lag is high ?
A synchronous replica via WAL shipping is a well-worn feature of Postgres. I’d expect RDS to be using that feature behind the scenes and would be extremely surprised if that has consistency bugs.
Two replicas in a “semi synchronous” configuration, as AWS calls it, is to my knowledge not available in base Postgres. AWS must be using some bespoke replication strategy, which would have different bugs than synchronous replication and is less battle-tested.
But as nobody except AWS knows the implementation details of RDS, this is all idle speculation that doesn’t mean much.
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#93Earlier quoted context omitted.
I wondered how Microsoft SQL Server fares, but not it's tested in the long list of databases: https://jepsen.io/analyses
It may violate the SQL Server license? Microsoft have not apparently paid for a Jepsen analysis (or perhaps don't want it public :))
> Microsoft have not apparently paid for a Jepsen analysis (or perhaps don't want it public :))
If I was some database vendor that sometimes plays fast and loose (not saying Microsoft is, just an example) and my product is good for 99.95% of use cases and the remainder is exceedingly hard to fix, I'd probably be more likely to pay for Jepsen not to do an analysis, because hiring them would result in people being more likely to leave an otherwise sufficient product due to those faults being brought to light.
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#94What safety or application-level bugs could arise if developers assume Snapshot Isolation but Amazon RDS for PostgreSQL is actually providing only Parallel Snapshot Isolation, especially in multi-AZ configurations using the read replica endpoint?
Consider a "git push"-like flow: begin a transaction, read the current state, check that it matches the expected, write the new state, commit (with a new state hash). In some unfortunate situations, you'll have a commit hash that doesn't match any valid state.
And the mere fact that it's hard to reason about these things means that it's hard to avoid problems. Hence, the easiest solution is likely "it may be possible to recover Snapshot Isolation by only using the writer endpoint", for anything where write is anyhow conditional on a read.
Although I'm surprised the "only using the writer endpoint" method wasn't tested, especially in availability loss situations.
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#95I wonder how Aurora fares on this?
Aurora doesn't offer Postgresql 17 for now I think
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#96> This work was performed independently by Jepsen, without compensation
not what a RDBMS stakeholder wants to wake up to on the best of days. I'd imagine there were a couple emails expressing concern internally.
hats off to aphyr as usual.
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#97> This work was performed independently by Jepsen, without compensation not what a RDBMS stakeholder wants to wake up to on the best of days. I'd imagine there were a couple emails expressing concern internally. hats off to aphyr as usual.
What's a "RDBMS stakeholder" ?
(Hats off to aphyr for sure!)
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#98> This work was performed independently by Jepsen, without compensation not what a RDBMS stakeholder wants to wake up to on the best of days. I'd imagine there were a couple emails expressing concern internally. hats off to aphyr as usual.
What's a "RDBMS stakeholder" ? (Hats off to aphyr for sure!)
The three layers of middlemanagement between engineers and whichever director owns this particular incarnation of RDS
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#99Earlier quoted context omitted.
Have one question So if snapshot violation is happening inside Multi-AZ instances, it can happen with a single region - multiple read replica kind of setup as well ? But it might be easily observable in Multi-AZ setups because the lag is high ?
A synchronous replica via WAL shipping is a well-worn feature of Postgres. I’d expect RDS to be using that feature behind the scenes and would be extremely surprised if that has consistency bugs. Two replicas in a “semi synchronous” configuration, as AWS calls it, is to my knowledge not available in base Postgres. AWS must be using some bespoke replication strategy, which would have different bugs than synchronous re…
This kind of replication can be configured in vanilla Postgres with something like ANY 3 (s1, s2, s3, s4) in synchronous_standby_names? Doc: https://www.postgresql.org/docs/current/runtime-config-repli...
Re: Jepsen: Amazon RDS for PostgreSQL 17.4
#100> This work was performed independently by Jepsen, without compensation not what a RDBMS stakeholder wants to wake up to on the best of days. I'd imagine there were a couple emails expressing concern internally. hats off to aphyr as usual.
What's a "RDBMS stakeholder" ? (Hats off to aphyr for sure!)
a stakeholder is anyone who has any business at all with the system - customer, engineer, manager, etc.
RDBMS - https://en.wikipedia.org/wiki/Relational_database#RDBMS