You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In SetIsBackfilling, we acquire locks in the following order:
std::lock_guard<decltype(lock_)> l(lock_);
...
const auto table_lock = TableInfo::LockForRead();
But in CatalogManager::DoSplitTablet, we call
auto source_table_lock = source_tablet_info->table()->LockForWrite();
...
RETURN_NOT_OK(ValidateSplitCandidate(*source_tablet_info));
and ValidateSplitCandidate calls IsBackfilling on the same table which is locked, and then acquires std::lock_guard<decltype(lock_)> l(lock_);, the same lock as above
The text was updated successfully, but these errors were encountered:
Summary:
In TableInfo::SetIsBackfilling, we acquire locks in the following order:
```
std::lock_guard<decltype(lock_)> l(lock_);
...
const auto table_lock = TableInfo::LockForRead();
```
But in CatalogManager::DoSplitTablet, we call
```
auto source_table_lock = source_tablet_info->table()->LockForWrite();
...
RETURN_NOT_OK(ValidateSplitCandidate(*source_tablet_info));
```
and ValidateSplitCandidate calls IsBackfilling on the same table which is locked, and then acquires the same table info instance-level lock as above.
The fix here is to re-order the locks in SetIsBackfilling to follow the same order as the locks acquired during `CatalogManager::DoTabletSplit`
Test Plan: Jenkins
Reviewers: bogdan, timur, mpolitov
Reviewed By: mpolitov
Subscribers: ybase
Differential Revision: https://phabricator.dev.yugabyte.com/D11763
In
SetIsBackfilling
, we acquire locks in the following order:But in
CatalogManager::DoSplitTablet
, we calland
ValidateSplitCandidate
callsIsBackfilling
on the same table which is locked, and then acquiresstd::lock_guard<decltype(lock_)> l(lock_);
, the same lock as aboveThe text was updated successfully, but these errors were encountered: