-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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: lock duplicated keys on insert-ignore & replace-nothing #42210
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -539,7 +539,7 @@ func TestOptimisticConflicts(t *testing.T) { | |
tk.MustExec("begin pessimistic") | ||
// This SQL use BatchGet and cache data in the txn snapshot. | ||
// It can be changed to other SQLs that use BatchGet. | ||
tk.MustExec("insert ignore into conflict values (1, 2)") | ||
tk.MustExec("select * from conflict where id in (1, 2, 3)") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this query can be removed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. May I know why the query is unnecessary? IMO, it mean to test the snapshot cache. We cache (1, 2) here and don't want to see the following select-for-update (L547) returns the cached row. Although, it won't read from the cache even when we forget to invalidate the cache because it will read from lock cache firstly now (also, we won't reuse the snapshot with for-update-ts now). I think it's ok to keep the query since the test point still makes sense. |
||
|
||
tk2.MustExec("update conflict set c = c - 1") | ||
|
||
|
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.
It seems mysql only locks unique keys as well.
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.
The behaviors of this part are not described in the documents yet, we could add them there.