Skip to content
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

Merged
merged 17 commits into from
Dec 3, 2020

Conversation

you06
Copy link
Contributor

@you06 you06 commented Nov 23, 2020

Signed-off-by: you06 you1474600@gmail.com

What problem does this PR solve?

Issue Number: close #21218

Problem Summary:

Currently point_get and batch_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 and batch_point_get.

How it Works:

When the key is pessimistically locked, other transactions will wait for it.

Related changes

  • Need to cherry-pick to the release-4.0

Check List

Tests

  • Unit test

Side effects

Release note

  • select for update locks exist keys in point_get and batch_point_get

Signed-off-by: you06 <you1474600@gmail.com>
@you06 you06 added the sig/transaction SIG:Transaction label Nov 23, 2020
@you06 you06 requested a review from a team as a code owner November 23, 2020 14:21
@you06 you06 requested review from XuHuaiyu and removed request for a team November 23, 2020 14:21
@github-actions github-actions bot added the sig/execution SIG execution label Nov 23, 2020
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
@you06
Copy link
Contributor Author

you06 commented Nov 23, 2020

/run-all-tests

@you06 you06 requested review from lysu and cfzjywxk November 23, 2020 14:50
@cfzjywxk cfzjywxk added the type/bugfix This PR fixes a bug. label Nov 24, 2020
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
@you06
Copy link
Contributor Author

you06 commented Nov 24, 2020

/run-all-tests

1 similar comment
@you06
Copy link
Contributor Author

you06 commented Nov 24, 2020

/run-all-tests

@you06
Copy link
Contributor Author

you06 commented Nov 25, 2020

/run-integration-ddl-test

@you06
Copy link
Contributor Author

you06 commented Nov 25, 2020

/run-integration-common-test

@you06 you06 changed the title txn: locks exist keys for point_get & batch_point_get executor: locks exist keys for point_get & batch_point_get Nov 25, 2020
Signed-off-by: you06 <you1474600@gmail.com>
Signed-off-by: you06 <you1474600@gmail.com>
executor/batch_point_get.go Outdated Show resolved Hide resolved
executor/batch_point_get.go Outdated Show resolved Hide resolved
executor/batch_point_get.go Outdated Show resolved Hide resolved
executor/batch_point_get_test.go Outdated Show resolved Hide resolved
executor/batch_point_get_test.go Outdated Show resolved Hide resolved
store/tikv/2pc.go Show resolved Hide resolved
}
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))
Copy link
Contributor

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?

Copy link
Contributor Author

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.

}
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))
Copy link
Contributor

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.

@cfzjywxk
Copy link
Contributor

cfzjywxk commented Dec 3, 2020

@jackysp @MyonKeminta PTAL

@cfzjywxk
Copy link
Contributor

cfzjywxk commented Dec 3, 2020

LGTM

@ti-srebot ti-srebot added the status/LGT1 Indicates that a PR has LGTM 1. label Dec 3, 2020
Copy link
Member

@jackysp jackysp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ti-srebot ti-srebot removed the status/LGT1 Indicates that a PR has LGTM 1. label Dec 3, 2020
@ti-srebot ti-srebot added the status/LGT2 Indicates that a PR has LGTM 2. label Dec 3, 2020
@you06
Copy link
Contributor Author

you06 commented Dec 3, 2020

The lock behavior's change brings something weird, do not merge this PR.

@you06
Copy link
Contributor Author

you06 commented Dec 3, 2020

The lock behavior's change brings something weird, do not merge this PR.

The problem is caused by some mistake, not this PR.

@cfzjywxk
Copy link
Contributor

cfzjywxk commented Dec 3, 2020

/merge

@ti-srebot ti-srebot added the status/can-merge Indicates a PR has been approved by a committer. label Dec 3, 2020
@ti-srebot
Copy link
Contributor

/run-all-tests

@ti-srebot
Copy link
Contributor

cherry pick to release-4.0 in PR #21483

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/execution SIG execution sig/transaction SIG:Transaction status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/bugfix This PR fixes a bug.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

txn: select for update does not lock multi column pk
4 participants