hardConceptScenarioMidSeniorStaff
Walk me through the transaction isolation levels and which anomalies each one permits.
6 min readUpdated 2026-08-15
Answer
Short answer
Each level is defined by the anomalies it allows: READ COMMITTED permits non-repeatable reads and phantoms, PostgreSQL's REPEATABLE READ is snapshot isolation so it prevents both yet still permits write skew, and only SERIALIZABLE rules out all four.
Was this answer helpful?
Likely follow-ups
- Why can PostgreSQL never produce a dirty read, even if you ask for READ UNCOMMITTED?
- How does SERIALIZABLE Snapshot Isolation detect a conflict that snapshot isolation cannot?
- What breaks about SELECT ... FOR UPDATE when the anomaly involves rows that do not exist yet?
- Why do InnoDB gap locks cause deadlocks that the same workload avoids under READ COMMITTED?
Related questions
- Two transactions each check a rule, then both commit changes that break it, and neither overwrote the other's row. What happened?hardAlso on write-skew and mvcc5 min
- A user submits the form twice and you get two identical orders. Why did the check-then-insert not prevent it, and how do you fix it in the database?hardAlso on transactions and isolation-levels6 min
- Two doctors can go off call only if at least one remains. Both check the rule at the same moment, both see two doctors on call, and both go off call. What isolation problem is this, and what actually fixes it?hardAlso on write-skew and transactions6 min
- You are getting a handful of deadlock errors an hour under load. How do you find the cause, and how do you stop them?hardAlso on transactions and postgresql7 min