Hacker News 上看到作者自己貼的：「Jepsen: MySQL 8.0.34 (jepsen.io)」，原文在「MySQL 8.0.34」。
這次的測試不是 Oracle 付費讓 Jepsen 測，而是 Jepsen 這邊自己回頭測試 MySQL 8.0：
This work was performed independently without compensation, and conducted in accordance with the Jepsen ethics policy.
然後意外的流彈 (或是榴彈？) 打下了 AWS 的 RDS，測出 RDS 在 cluster 模式下無法達到 SERIALIZABILITY：
As a lagniappe, we show that AWS RDS MySQL clusters routinely violate Serializability.
然後 MySQL 本體則是找到 REPEATABLE-READ (預設 isolation level) 的問題：
Using our transaction consistency checker Elle, we show that MySQL Repeatable Read also violates internal consistency. Furthermore, it violates Monotonic Atomic View: transactions can observe some of another transaction’s effects, then later fail to observe other effects of that same transaction. We demonstrate violations of ANSI SQL’s requirements for Repeatable Read.
文章的前面一大段在寫歷史，解釋 ANSI 當初的 SQL 標準在定義 isolation level 時寫的很差，導致有很多不同的解讀，而且即使到了 SQL:2023 也還是沒有改善。
接著則是提到各家資料庫宣稱的 isolation level 跟 ANSI 定義的又不一樣的問題... (包括了無論怎麼解讀 ANSI 定義的情況)
不過中間有提到 1999 年 Atul Adya 試著正式定義 isolation level，把本來的四個 isolation level 用更嚴謹的方法重新給出相容的定義，這看起來是作者推薦在一般狀況下的替代方案：
In 1999, Atul Adya built on Berenson et al.’s critique and developed formal and implementation-independent definitions of various transaction isolation levels, including those in ANSI SQL. As he notes[.]
這四個會是 PL-1 對應到 READ UNCOMMITTED，PL-2 對應到 READ COMMITTED，PL-2.99 對應到 REPEATABLE-READ，以及 PL-3 對應到 SERIALIZABILITY；而其中 PL-2.99 的 REPEATABLE-READ 在後面也會重複出現多次。
這次比較意外是在單機上找出問題來，至於 RDS 的部分反倒不是太意外，因為知道 AWS 在底層做了不少 hack，總是會有些 trade off 的？
