distributed systems / LEVEL 5
THEORY / RETRIEVAL
PostgreSQL Repeatable Read gives each transaction a stable snapshot, but concurrent transactions can still form a serialization anomaly. If two doctors both observe two people on call and each updates only their own row, both disjoint writes can commit while the cross-row invariant becomes false. Locking only the row each transaction writes does not coordinate the predicate they both read.
PostgreSQL Serializable admits only commits compatible with some serial order. When dependency monitoring cannot prove such an order, one transaction fails with SQLSTATE 40001. The application must discard every result from that attempt and rerun the complete decision transaction from a fresh snapshot, including the reads that chose which SQL and values to use.
A generic boundary can retry 40001 and, by explicit policy, deadlock 40P01. Unique violations and domain errors are normally returned immediately because they may be permanent; retry them only when application-specific evidence proves a transient concurrency cause. Bound total attempts, preserve the command or idempotency key, and place jittered delay outside this synchronous helper so overload does not synchronize retries.
CHECKPOINT
02 / DEBUGGING
Repair `run_serializable`. `max_attempts` is the total invocation budget, not the number of retries. Invoke the closure with the same command id every time; retry only SerializationFailure or DeadlockDetected while budget remains. Return success, UniqueViolation, Domain, or the final retryable error immediately when required. The closure represents a fresh complete SERIALIZABLE transaction on every invocation; async backoff and jitter belong to its caller.
Runner is waiting for a submission.