-
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
executor, store/tikv: locks exist keys for point_get & batch_point_get #21229
Conversation
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
/run-all-tests |
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
/run-all-tests |
1 similar comment
/run-all-tests |
/run-integration-ddl-test |
/run-integration-common-test |
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
executor/batch_point_get_test.go
Outdated
} | ||
tk2.MustExec(fmt.Sprintf("insert into %s values(5, 5, 5)", tableName)) | ||
go func() { | ||
tk2.MustExec(fmt.Sprintf("insert into %s values(4, 4,40)", tableName)) |
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.
We could use the lock error returned by the select * from t where (id, v) in (4, 4, 40) for update nowait
to verify the lock does exist.
MustExec
in anohter goroutine seems will not cause test failure if failed?
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.
select for update nowait
statement will lead to fail due to lock on row key, I use an err channel to collect the exec error and assert it in the test function.
executor/point_get_test.go
Outdated
} | ||
tk2.MustExec(fmt.Sprintf("insert into %s values(3, 3, 3)", tableName)) | ||
go func() { | ||
tk2.MustExec(fmt.Sprintf("insert into %s values(2, 2, 20)", tableName)) |
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.
We could check locks like above.
Signed-off-by: you06 <you1474600@gmail.com>
@jackysp @MyonKeminta PTAL |
LGTM |
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
The lock behavior's change brings something weird, do not merge this PR. |
The problem is caused by some mistake, not this PR. |
/merge |
/run-all-tests |
cherry pick to release-4.0 in PR #21483 |
pingcap#21229) Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
Signed-off-by: you06 you1474600@gmail.com
What problem does this PR solve?
Issue Number: close #21218
Problem Summary:
Currently
point_get
andbatch_point_get
only lock keys when row is not exist, this may result in unexpected failure.What is changed and how it works?
What's Changed:
Lock all keys in
point_get
andbatch_point_get
.How it Works:
When the key is pessimistically locked, other transactions will wait for it.
Related changes
Check List
Tests
Side effects
Release note
select for update
locks exist keys inpoint_get
andbatch_point_get