Two transactions, many truths

Drive T1 and T2 below, or run a scenario. Then change the isolation level and the recorded interleaving is re-evaluated from scratch — watch dirty reads, non-repeatable reads, phantoms and lost updates appear or get blocked. This models MVCC snapshot isolation (as in PostgreSQL), so Repeatable Read here also prevents phantoms.

row x = 100 (v0) committed rows = 3

Change the level at any time — the recorded interleaving is re-evaluated under the new rules. Because this follows the PostgreSQL snapshot model, raising a phantom scenario from Read Committed to Repeatable Read makes the phantom vanish, even though the SQL standard technically permits it at that level.

Scenarios:
T1 idle
    T2 idle

      No operations yet. Click an op on T1 or T2, or run a scenario.

      MVCC version chain — row x xmin = created by · xmax = superseded by

      Each WRITE appends a new version instead of overwriting. A transaction sees the newest version its snapshot is allowed to see. Old versions linger as dead tuples until vacuum reclaims them. (INSERTs for COUNT(*) are tracked separately and not drawn here.)

      Step log interleaved, oldest first