Back to the catalog

Database isolation and consistency: CAP, isolation levels, and locking

35 questions

CAP, isolation levels, and locking, as the docs and papers define them. Learn why partition tolerance is never optional, what PostgreSQL's default Read Committed lets through, why snapshot isolation allows write skew, how linearizability differs from serializability, and when to use SELECT ... FOR UPDATE, an advisory lock, or a version column.

Questions

  1. Not answered. In Gilbert and Lynch's formulation of CAP, why can't you just choose not to tolerate partitions?
  2. Not answered. Does the C in CAP mean the same thing as the C in ACID?
  3. Not answered. What does the ELC half of Abadi's PACELC add to the picture that CAP leaves out?
  4. Not answered. How do linearizability and serializability differ as correctness properties?
  5. Not answered. When a distributed database's marketing promises "strong consistency," which formal property does it almost always mean?
  6. Not answered. What does strict serializability guarantee that plain serializability does not?
  7. Not answered. Herlihy and Wing proved that linearizability is local (composable). What does that give you, and does serializability have it too?
  8. Not answered. A read-only transaction at SERIALIZABLE returns data you know is out of date. Has the database violated serializability?
  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. Not answered. What is the strongest consistency model a system can offer if it must stay available under any partition and still converge?
  11. Not answered. Which transaction isolation level does a stock PostgreSQL server use when you BEGIN without specifying one?
  12. Not answered. PostgreSQL accepts all four SQL-standard isolation level names. How many levels with distinct behavior does it actually implement?
  13. Not answered. At READ COMMITTED, when does PostgreSQL take the snapshot a query sees?
  14. Not answered. What does the concurrent DELETE do, and why?
  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. Not answered. Both transactions commit successfully. What is the final balance, and what is this anomaly called?
  17. Not answered. Which of these anomalies does PostgreSQL's REPEATABLE READ prevent?
  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. Not answered. PostgreSQL aborts your transaction with SQLSTATE 40P01. What happened, and what should the client do?
  20. Not answered. Both transactions commit and nobody is left on call. Why did snapshot isolation allow it?
  21. Not answered. Snapshot isolation uses the first-committer-wins rule to detect conflicts. Which kind of conflict can it never see?
  22. Not answered. PostgreSQL's Serializable Snapshot Isolation aborts a transaction when it spots a "dangerous structure." What is that structure?
  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. Not answered. How does SSI's approach to serializability differ from classic two-phase locking?
  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. Not answered. Why does SELECT ... FOR UPDATE fail to prevent this double booking?
  27. Not answered. What is the practical difference between pg_advisory_lock(key) and pg_advisory_xact_lock(key)?
  28. Not answered. Which PostgreSQL function takes an exclusive advisory lock that is released automatically when the transaction ends?
  29. Not answered. At READ COMMITTED, why does a version-column UPDATE reliably detect a concurrent change, even though the transaction read the row minutes earlier?
  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. Not answered. Which of these approaches, used correctly, prevent the double booking?
  32. Not answered. What does Oracle's SERIALIZABLE isolation level actually implement?
  33. Not answered. Which isolation level does MySQL's InnoDB engine use by default?
  34. Not answered. In the Adya-style anomaly taxonomy that Jepsen's Elle checker uses, what does G1a describe?
  35. Not answered. Every transaction now runs at SERIALIZABLE with a retry loop. Which kind of bug does this still leave untouched?