Write Skew — Two Doctors, Zero On Call Diagram

Anatomy of Write Skew

Each transaction checks a requirement with a SELECT, decides based on what it saw, then writes — and the write invalidates the premise of the check
It is not a dirty write and not a lost update: the two transactions touch two different rows
It is a generalization of lost updates — different objects, same pattern of a decision on stale data
Had the two transactions run one after another, the second doctor would have been blocked from going off call

The Same Shape in Other Systems

Meeting rooms: two bookings for the same room and time are inserted after both see no conflict
Username claims: two accounts register the same name — here a uniqueness constraint is the simple fix
Multiplayer games: two different figures move to the same square on the board
Double spending: two tentative spends together drive the balance negative while neither sees the other

Why the Cheap Remedies Do Not Work

Atomic single-object operations cannot help — several objects are involved in the decision
Lost-update detection in snapshot isolation does not catch write skew in PostgreSQL, MySQL, Oracle, or SQL Server
A constraint over several rows (at least one doctor on call) is not built in; triggers or materialized views are the workaround
SELECT FOR UPDATE on the rows you read is the second-best option; serializable isolation is the real answer