@rior Yeah, students have gotten in touch from time to time, but none of them have started the actual thesis yet to my knowledge. Sometimes academics just... pass off a bunch of Jepsen work as their own too, that's fun. ;-)
@rior I mean, I don't blame them: this work is kind of exhausting, haha. I don't think many people wake up and think "yeah I really wanna take the next six weeks of vacation to dig into obscure papers and MySQL isolation behavior"
@rior I mean, in theory yeah, it's very parallelizable. But in practice... the tools have been free for seven years, and few people are doing Jepsen stuff independently. Mostly it's at specific vendors, and the rigor of their test suites varies wildly.
@rior Yeah, that's about about 10 minutes of work on a typical contract. That's not to say it's not a meaningful and good amount of money, it's just... it wouldn't let me do anything I can't *already* offer for free. My limits are time, energy, emotional bandwidth, not funds right now.
I'm very cognizant that this is an extremely privileged position to be in--it has only been this way for a short time, and that calculus could change.
@rior The problem is that like... when people talk about donations they usually mean $5 or 10/mo. Jepsen's standard contract rate is four orders of magnitude higher than that.
@rior I'm serious about Jepsen's independence, and do my best to be rigorous regardless of funding, but there could be subconscious influences there. This is also why I don't accept equity compensation--trying to keep conflicts to a minimum. If I offer voting on "pro-bono" analyses in exchange for sponsorship, then that introduces a direct conflict.
Anyway, if you have strong feelings, drop em here.
It's also, like... Jepsen is roughly 50/50 paid vs unpaid work right now. Jepsen contract rates are high, which covers research, maintenance, and writing in between. It's hard to imagine sponsors could materially shift that balance.
On the other hand, this presents a conflict-of-interest problem: so long as reports have a single sponsor (typically the vendor), it's easy to disclose and understand, but that's much trickier when there's a mix of a dozen ongoing sponsors.
@rior I wouldn't use it *yet*--it's still in early development. But yeah, once this solidifies, there's no reason it shouldn't be comparable to etcd/consul as a distributed in-memory data structure server, with richer datatypes. I wouldn't compare it to something like FoundationDB, unless your entire dataset fits in memory.
Right now Redis makes a great cache, lossy message bus, and scratchpad, but you have to plan on data loss. Redis-Raft should hopefully change that by offering strict serializability, and from our testing, it looks like they're on track. Watch for GA next year!
Redis-Raft is really cool, because of the existing Redis replication strategies (Sentinel, Cluster, Enterprise, CRDT), all of them can lose updates during partitions.
There are a ton of neat bugs here, including infinite loops, total data loss on failover, servers sending responses to the wrong clients, and all kinds of crashes. None should have affected production users; Redis-Raft wasn't public until May, and GA isn't until 2021.
New Jepsen analysis: we worked with Redis Labs to evaluate Redis-Raft, a new, still-under-development approach to Redis replication, and found 21 issues, 20 of which have been fixed in recent builds. https://jepsen.io/analyses/redis-raft-1b3fbf6
I'm gonna be giving a Zoom talk on Elle for CMU's database seminar, on July 27th. I think anyone can join, if you want to listen in. :) https://db.cs.cmu.edu/events/db-seminar-spring-2020-db-group-black-box-isolation-checking-with-elle/
@jepsen_io Completely agreed! I'm aware of a few other instances of reported non-serializable behavior under PostgreSQL SSI: https://www.postgresql.org/message-id/20141021071458.2678.9080%40wrigleys.postgresql.org https://email@example.comfirstname.lastname@example.org Repros: https://github.com/gfredericks/pg-serializability-bug
Anyway, consistency models are a mess; news at 11. 😂
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!