@Keleesssss Maybe the real pro strat is to fuzz at versionstamped keys because I was learning how the client code worked while I was implementing it :p
@Keleesssss If your fuzzer is fine with it, you should also use the multi-version client (with an incorrectly versioned internal libfdb_c) because all of that code isn’t simulation testable well
@Keleesssss Bah, the stupid read-your-writes map thing. It would not surprise me if there’s more weird corner cases hiding in the edges of atomic ops + other client features. There’s only super random unguided fuzzing looking for API errors.
@you_da_way My guess is that it just wasn't a big priority? AFAICT, UFS doesn't actually fsync anyway. 🤷
@kostikbel2, if you ever happen to check back in to twitter, I too would be interested in if you remember what the background/motivation for https://t.co/xGqjsDE3xf was
@tzkb There was no neon paper, this is the first. They previously had a blog post on their choice of Paxos over Raft because the ability to separate the proposer, so it is odd to call it raft-like. Let’s maybe not immediately fully buy into the “3rd gen” marketing.
@penberg@vanlightly I’d have to work through the cases more, but the quorum-on-join possibly does make VSR have less availability issues if you follow the default implementation
https://t.co/vbC7yilbjP
However, all the human effort writing about availability corner cases is about Raft, so…
@penberg@vanlightly Being able to choose a node as leader based on fitness rather than log length is nice, but VSR’s default deterministic rotation there doesn’t help achieve that goal either.
The quorum before rejoin sounds nice too, but with durable storage I haven’t found why it matters.
@mmalisper@LeoOliemans91 Then why are you waiting until the fsync starts, even? If you’re already doing the “fix the read anomaly” part of early lock release, then just doesn’t classic ELR drop the locks after you get the WAL position? Does PG have no seam between WAL enqueue and fsync?