Skip to content

Conversation

@laurynas-biveinis
Copy link
Contributor

No description provided.

@laurynas-biveinis
Copy link
Contributor Author

This is a draft pull request: prerequisite branches not removed, there are test failures, including crashes, and not all the review comments have been addressed yet. But it should be possible to continue reviewing code

laurynas-biveinis and others added 3 commits April 29, 2024 13:41
- Add new sysvar, rocksdb_use_range_locking. When it's on:
- RocksDB is initialized to used range-locking lock manager
- For all DML operations (including SELECT ... FOR UPDATE), the scanned range
  will be locked before reading/modifying rows
- For all DML operations, MyRocks will read and modify the latest committed
  data, just like InnoDB does, because there is no snapshot checking if range
  locking is used.
- Introduce a RocksDB locking iterator, which reads the rows, locks the range,
- and re-reads the rows. It is used for queries that do not have a finite range
  to scan, like UPDATE t1 ... ORDER BY t1.key LIMIT n
- Add another new sysvar, rocksdb_use_range_lock_manager_as_point, which uses
  the point locking algorithm but the lock manager used is the range one.
- Add enabled rocksdb_use_range_locking as another MTR rocksdb suite test
  combination.

Co-authored-by: Sergei Petrunia <sergey@mariadb.com>
Co-authored-by: Laurynas Biveinis <laurynas.biveinis@gmail.com>
@luqun luqun changed the title Myr range locking Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

2 participants