core practice · coding problem
Detect write skew under snapshot isolation
Two transactions each read the same snapshot and then write DIFFERENT rows based on what they read — snapshot isolation permits this, and the invariant breaks. Implement wouldSkew(t1, t2) where each transaction is { reads: string[], writes: string[] }. Return true when they are a write-skew risk: their read sets overlap, at least one transaction writes a row the OTHER read, and they write disjoint rows. Return false otherwise.
The mechanism
An isolation level is a contract about which anomalies you are willing to see, not a dial labelled 'safety'. Read Committed still allows non-repeatable reads; Snapshot Isolation gives every transaction a consistent point-in-time view and still permits write skew, because two transactions can each read a state the other is about to invalidate. MVCC is the implementation trick that makes those snapshots cheap — writers create new versions instead of overwriting, so readers never block writers, at the cost of version storage and vacuum.
Expected evidence
wouldSkew({reads:['a','b'],writes:['a']},{reads:['a','b'],writes:['b']}) -> trueTry this drill in the practice workspace →
Hints when you need them
- Disjoint writes are what makes it invisible to first-committer-wins conflict detection.
- The danger sign is a write landing on a row the other transaction based its decision on.
Watch for these mistakes
- Reading a vendor's level name as the standard's — Oracle and PostgreSQL 'Serializable' historically meant different guarantees
- Assuming Snapshot Isolation prevents all anomalies; write skew survives it and needs SELECT FOR UPDATE or true serializability
- Forgetting MVCC's cost: long-running readers pin old versions and bloat the table
- Raising the isolation level to fix a bug whose real cause is a missing constraint