c9878baa87
Summary: Fix this scenario: trx1> acquire shared lock on $key trx2> acquire shared lock on the same $key trx1> attempt to acquire a unique lock on $key. Lock acquisition will fail, and deadlock detection will start. It will call iterate_and_get_overlapping_row_locks() which will produce a list with two locks (shared locks by trx1 and trx2). However the code in lock_request::build_wait_graph() was not prepared to find the lock by the same transaction in the list of conflicting locks. Fix it to ignore it. (One may suggest to fix iterate_and_get_overlapping_row_locks() to not include locks by trx1. This is not a good idea, because that function is also used to report all locks currently held) Pull Request resolved: https://github.com/facebook/rocksdb/pull/7938 Reviewed By: zhichao-cao Differential Revision: D26529374 Pulled By: ajkr fbshipit-source-id: d89cbed008db1a97a8f2351b9bfb75310750d16a |
||
|---|---|---|
| .. | ||
| range_tree | ||
| range_lock_manager.h | ||
| range_locking_test.cc | ||