Range Locking support, MyRocks part #1185
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When it is ON, MyRocks will:
- initialize RocksDB to use range-locking lock manager
- for all DML operations (including SELECT .. FOR UPDATE) will lock
the scanned range before reading/modifying rows.
- In range locking mode, there is no snapshot checking (cannot do that
for ranges). Instead, MyRocks will read and modify latest committed
data, just like InnoDB does (in the code, grep for (start|end)_ignore_
snapshot)
- Queries that do not have a finite range to scan, like
UPDATE t1 .... ORDER BY t1.key LIMIT n
will use a "Locking iterator" which will read rows, lock the range,
and re-read the rows. See class LockingIterator.
|
@hermanlee has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
|
Tracking some additional issues found so far:
|
|
There is a use-after-free which caused the problem. The transaction clean-up is not removing the transaction from the lock manager's wait list correctly. Report from asan: |
|
The range lock manager currently uses the address of the PessimisticTransaction object as the TXNID in the locktree. Various different callbacks cast this address back to PessimisticTransaction to get the rocksdb assigned transaction ID for reporting purposes. However, other than the callbacks made when walking a locktree's request queue where a mutex is held to guarantee those pending lock requests (and consequently PessimisticTransactions) are still active, most of the other callbacks are invoked without holding any type of mutex or reference count to prevent the PessimisticTransaction from being freed. It seems the following scenario is occurring:
|
|
Updated version: #1430 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(Range Locking pull request,filed against fb-mysql-8.0.23)
This adds a my.cnf parameter, rocksdb_use_range_locking.
When it is ON, MyRocks will:
the scanned range before reading/modifying rows.
for ranges). Instead, MyRocks will read and modify latest committed
data, just like InnoDB does (in the code, grep for (start|end)ignore
snapshot)
UPDATE t1 .... ORDER BY t1.key LIMIT n
will use a "Locking iterator" which will read rows, lock the range,
and re-read the rows. See class LockingIterator.