What Your Database Actually Promises: Isolation & Consistency

Questions

1. 1
   Not answered. In the Gilbert-Lynch formulation of CAP, why is "just don't tolerate partitions" not an available design option?
2. 2
   Not answered. Does the C in CAP mean the same thing as the C in ACID?
3. 3
   Not answered. What does the ELC half of Abadi's PACELC add to the picture that CAP leaves out?
4. 4
   Not answered. How do linearizability and serializability differ as correctness properties?
5. 5
   Not answered. When a distributed database's marketing page promises "strong consistency," which formal property does it almost always mean?
6. 6
   Not answered. What does strict serializability guarantee that plain serializability does not?
7. 7
   Not answered. Herlihy and Wing proved that linearizability is a local (composable) property. What does that buy you, and does serializability share it?
8. 8
   Not answered. A read-only transaction at SERIALIZABLE returns data you know is out of date. Has the database violated serializability?
9. 9
   Not answered. Bailis et al. asked which isolation levels a system can provide while remaining available during a partition. Which of these made the cut?
10. 10
    Not answered. For a system that must stay available under arbitrary partitions and converge, what is the strongest consistency model it can offer?
11. 11
    Not answered. Which transaction isolation level does a stock PostgreSQL server use when you BEGIN without specifying one?
12. 12
    Not answered. PostgreSQL accepts all four SQL-standard isolation level names, but how many behaviourally distinct levels does it actually implement?
13. 13
    Not answered. At READ COMMITTED, when is the snapshot that a query sees actually taken?
14. 14
    Not answered. What does the concurrent DELETE do, and why?
15. 15
    Not answered. Two sessions concurrently run UPDATE accounts SET balance = balance - 100 WHERE id = 1 at READ COMMITTED. Is one of the deductions lost?
16. 16
    Not answered. Both transactions commit successfully. What is the final balance, and what is this anomaly called?
17. 17
    Not answered. Which of these anomalies does PostgreSQL's REPEATABLE READ prevent?
18. 18
    Not answered. Which five-character SQLSTATE code does PostgreSQL return when a transaction must be rolled back and retried because of a serialization failure?
19. 19
    Not answered. PostgreSQL aborts your transaction with SQLSTATE 40P01. What happened, and what should the client do?
20. 20
    Not answered. Both transactions commit and nobody is left on call. Why did snapshot isolation allow it?
21. 21
    Not answered. Snapshot isolation's first-committer-wins rule is described as its conflict detector. What class of conflict is it structurally unable to see?
22. 22
    Not answered. PostgreSQL's Serializable Snapshot Isolation aborts a transaction when it spots a "dangerous structure." What is that structure?
23. 23
    Not answered. Your reporting job runs at SERIALIZABLE, but the writer that updates the same rows runs at the default level. Is the reporting job still protected from serialization anomalies?
24. 24
    Not answered. How does SSI's approach to serializability differ from classic two-phase locking?
25. 25
    Not answered. At READ COMMITTED, a SELECT ... FOR UPDATE blocks on a row another transaction is updating. When that transaction commits, what does your query return?
26. 26
    Not answered. Why does SELECT ... FOR UPDATE fail to prevent this double booking?
27. 27
    Not answered. What is the practical difference between pg_advisory_lock(key) and pg_advisory_xact_lock(key)?
28. 28
    Not answered. Which PostgreSQL function takes an exclusive advisory lock that is released automatically when the transaction ends?
29. 29
    Not answered. At READ COMMITTED, why does a version-column UPDATE reliably detect a concurrent modification, even though the transaction read the row minutes earlier?
30. 30
    Not answered. Which locking clause should a SELECT use so that concurrent plain UPDATEs to a row's non-key columns are still allowed, while DELETEs and key changes are blocked?
31. 31
    Not answered. Which of these approaches, applied correctly, actually prevent the double booking?
32. 32
    Not answered. Oracle's SERIALIZABLE isolation level: what does it actually implement?
33. 33
    Not answered. Which isolation level does MySQL's InnoDB engine use by default?
34. 34
    Not answered. In the Adya-style anomaly taxonomy that Jepsen's Elle checker uses, what does G1a describe?
35. 35
    Not answered. You have set every transaction to SERIALIZABLE and added retry loops. Which class of bug does this still leave completely untouched?