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 Myrocks range locking Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants