= Transaction isolation
<Transaction isolation> specifies which effects <concurrent computing>[concurrent] <database transaction>[database transactions] may observe and which interleavings are permitted to commit. Serializable isolation requires the combined result to be equivalent to some serial ordering, even when execution actually overlaps. Weaker levels admit particular anomalies; their names require implementation-specific interpretation.<Transaction Isolation in the PostgreSQL documentation>[§13.2, definitions and isolation-level table]{ref}
For example, two doctors are on call. Each transaction reads that both are available and removes its own doctor, intending to leave someone on call. If each sees an old snapshot and they update different rows, both may commit under a snapshot-based level that does not prevent this write skew. No serial ordering would let both checks pass. PostgreSQL Serializable can reject such conflicting executions, so the application must be prepared to retry a whole transaction. Isolation protects a stated concurrency model; it does not repair a faulty business rule within one transaction.
Back to article page
