Show more

RT @andy_pavlo
@jepsen_io .@halberenson sent me an amazing email last year about why the ANSI SQL isolation levels got muddied up. I'm sure he can share more details about what happened.

Anyway, consistency models are a mess; news at 11. 😂

Show thread

So, while Berenson et al. say that snapshot isolation isn't stronger than repeatable read, PostgreSQL appears to have implicitly adopted the strict interpretation instead, and says that SI is stronger than RR. In fact, SI prohibits *every* anomaly in the strict interpretation of the ANSI SQL standard, including their (narrow) definition of phantoms!

Show thread

This could still be consistent with the ANSI SQL standard's definition of repeatable read! As Berenson et al. pointed out twenty five years ago (!), the standard is ambiguous. The paper argues that there are two interpretations of the ANSI phenomena: strict, and broad. They say the broad interpretation is what ANSI *meant* to define, and goes on to define and analyze snapshot isolation in those terms. microsoft.com/en-us/research/w

Show thread

Something odd came up during this review, which Martin Kleppmman previously reported in github.com/ept/hermitage/blob/: PostgreSQL repeatable read isn't repeatable read: it's snapshot isolation, which allows a specific class of G2-item anomalies (those with nonadjacent rw edges) prohibited under formalizations of repeatable read.

Show thread

A new Jepsen report! It turns out that PostgreSQL's "serializable" isolation was not, in fact, serializable: it exhibited G2-item. A patch is coming in the next minor release. :) jepsen.io/analyses/postgresql-

Manish Jain, from Dgraph Labs, wrote a bit about his experience debugging Jepsen test failures, and how he used OpenCensus traces to get a handle on some tricky bugs: dgraph.io/blog/post/solving-je

So here's a neat thing postgres 12.3 might do? Maybe I'm doing it wrong, not sure yet.

All these transactions are executed with SERIALIZABLE isolation over lists implemented as comma-separated TEXT fields. `r x [1, 2]` means we read the current value of row x and found it to be [1,2]. `a x 3` means "append 3 to x", like so:

insert into txn1 as t (id, val) values ($1, $2) on conflict (id) do update set val = concat(t.val, ',', $3) where t.id = $4

rw is an anti-dep, ww and wr are deps.

"Note: Because of the way synchronous replication is implemented in PostgreSQL it is still possible to lose transactions even when using synchronous_mode_strict"

oh, okay, cool

is there a postgres replication/HA setup that *doesn't* lose data?

github.com/zalando/patroni/blo

Show thread

Anyway, moving on: I'd like to hear from y'all about what kind of Postgres replication you think is safest. Patroni, perhaps?

I called this out in the report as well, but the write concern documentation still doesn't say anything about rollbacks/write loss: docs.mongodb.com/manual/refere

Show thread

If users are really aware of, and OK with, with write loss by default (presumably because the probability of failure is small or the impact is low) then it should be fine to talk about it. If users *aren't* aware of this behavior, but most are subject to it by accepting defaults, then of *course* you should educate people about it!

Or, you know, choose safer defaults. That's an option!

Show thread

I keep thinking about their VLDB paper which says ~80% of writes to MongoDB's hosted service don't set a write concern, and 99.6% of reads don't set a read concern. vldb.org/pvldb/vol12/p2071-sch

Show thread

MongoDB rewrote their Jepsen page, but it still goes to great lengths to avoid talking about write loss or aborted reads, both of which are the default behavior:

mongodb.com/jepsen

Show thread

MongoDB found a bug in the retry mechanism which they think is responsible for the issues we found in 4.2.6--a fix is scheduled for 4.2.8!

jira.mongodb.org/browse/SERVER

I mean like... 91 points and never even *touched* front page? I know, I know, never read Hacker News, but this is... weird behavior. I know Jepsen's gotten accidentally nuked by the voting ring detector in the past; maybe that's happening again.

Show thread

Did HN's antispam measures get a lot more aggressive recently? The last handful of Jepsen reports have really struggled to make it to frontpage, despite significantly higher vote-to-age ratios than comparable posts. Once they're on FP, they reliably hit top 10, but Dgraph's actually had to get rescued by a mod, and yesterday's Mongo post never made it past mid-second-page.

To be clear, I don't encourage anyone else to submit or upvote, don't pass around HN page links, submit exactly once, etc.

Also the `snapshot` read concern doesn't actually give you snapshot reads unless you commit with write concern `majority`, and apparently this is... by design? Even for read-only transactions? I have questions!

Show thread

tl;dr: MongoDB 4.2.6's transactions aren't full ACID, or even snapshot isolated. We found read skew, cyclic information flow, and internal inconsistencies, including transactions which could read their own writes from the future. Ooooh, spooooky!

Also transactions are allowed to lose data & read uncommitted, possibly impossible states by default, because why would you *not* want that behavior from something called a transaction. This was already documented, but I found it surprising!

Show thread
Show more
Jepsen

A single-user Mastodon instance for Jepsen announcements & discussion.