-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
memdb: fix data race between mutators and UnionScan
#20365
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@crazycs520, Thanks for your review, however we are sorry that your vote won't be count. |
/run-all-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/merge |
@zz-jason Oops! This PR requires at least 2 LGTMs to merge. The current number of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/merge |
/run-all-tests |
What problem does this PR solve?
Fix data race found in https://internal.pingcap.net/idc-jenkins/blue/organizations/jenkins/tidb_ghpr_unit_test/detail/tidb_ghpr_unit_test/54258/pipeline/
What is changed and how it works?
After #19276 the
UnionScan
executor will read the immutable snapshot part ofmemdb
to avoid data race. Unfortunately, the collection of uderlaying blocks may be updated whileUnionScan
collecting data.To resolve this issue, I simply use a
Mutex
to protect operations onarena.blocks
. The reason for useMutex
is the fast path is a single atomic CAS instruction which is much faster thanRWMutex
.Check List
Tests
Release note