Use when two concurrent database transactions can touch the same rows (balance debits, seat bookings, stock counts), or before changing a default isolation level. Tests which anomalies each level prevents (dirty, non-repeatable and phantom reads, write skew) in PostgreSQL, MySQL and SQL Server.
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Companion to mvcc-isolation-tests. Defaults and anomalies differ, so
port the SKILL.md tests to the database you ship and re-check each
expectation; do not assume PostgreSQL results carry over.
| Database | Default level | Repeatable Read and phantoms | Notes |
|---|---|---|---|
| PostgreSQL | Read Committed | No phantoms (snapshot); write skew still possible | Read Uncommitted behaves as Read Committed; Serializable aborts with SQLSTATE 40001 and the app retries (PostgreSQL) |
| MySQL InnoDB | Repeatable Read | Plain reads use the snapshot from the first read; locking reads and UPDATE / DELETE take gap or next-key locks | Mixing plain and locking reads in one transaction reads two different states; Serializable turns plain SELECT into SELECT ... FOR SHARE when autocommit is off (MySQL) |
| SQL Server | Read Committed (READ_COMMITTED_SNAPSHOT off on SQL Server, on in Azure SQL Database) | Phantoms allowed; only Serializable blocks them with range locks | With RCSI on, Read Committed reads a per-statement row-version snapshot instead of taking shared locks; SNAPSHOT needs ALLOW_SNAPSHOT_ISOLATION on (SQL Server) |
READ COMMITTED (the
default Repeatable Read prevents it). The write-skew pair under
Repeatable Read with plain SELECT behaves as in PostgreSQL; with
SELECT ... FOR UPDATE the second transaction blocks instead, so the
harness's hang check fires - assert the block, not the skew.SerializationFailure); MySQL and SQL Server report deadlock or
lock-timeout errors instead. Retry on the error your driver raises.