![](https://secure.gravatar.com/avatar/3bce7f356a04335a99fe8b1a74a04e02.jpg?s=120&d=mm&r=g)
Hi Kyle,
On Fri, Dec 22, 2023 at 6:36 PM Kyle Kingsbury via discuss
On 12/21/23 05:14, Marko Mäkelä wrote:
Heikki Tuuri implemented locking reads in a peculiar way: They are actually always READ COMMITTED, and the read view is being ignored. I do not remember it clearly, but I heard from a former member of the MySQL Falcon storage engine team that they called some of the InnoDB anomalies "write committed". It could be exactly this.
Oh that's *very* interesting! I hadn't heard of this--I'll have to take a look.
In row0sel.cc, inside the function row_search_mvcc() or its callees, you will find calls to lock_clust_rec_read_check_and_lock() and lock_sec_rec_read_check_and_lock(). After those calls, we fail to check if the DB_TRX_ID of the successfully locked record is visible in our read view. If not, we could throw an error. That could fix these anomalies, hopefully all of them. I would like to see an experimental patch to do that. Once we have that, it should be possible to evaluate the impact to other applications, and then maybe introduce a new isolation level REPEATABLE LOCKING READ or something. The code is also duplicated in the function row_sel(), which is for the InnoDB internal SQL parser that is used for things like updating some internal tables for FULLTEXT INDEX, updating the InnoDB persistent statistics tables, or DDL operations. With best regards, Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc