core/filtermaps: fix range delete deadlock #31704
Closed
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.
This PR fixes a deadlock situation is
deleteTailEpoch
that might arise when range delete is running in iterator based fallback mode (either using leveldb database or the hashdb state storage scheme). In this case astopCb
callback is called periodically that does check events, including matcher sync requests, in which case it tries to acquireindexLock
for write access, whiledeleteTailEpoch
already held it for read access. This callback is called in every other case withindexLock
unlocked so this PR unlocks it while the actual data removal is happening. Marking the old map range unindexed happens before the actual deletion and happens undexindexLock
. Marking the epoch either clean or dirty depending on whether the deletion is finished is again happening while the lock is being held.Fixes #31700