-
Notifications
You must be signed in to change notification settings - Fork 225
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
Allow configuring the policy when prewrite encounters lock #1501
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: ekexium <[email protected]>
…unter-lock-policy
08b47b2
to
8ce525d
Compare
Signed-off-by: ekexium <[email protected]>
8ce525d
to
fa81972
Compare
The comparison data between this PR and master in description is same, is there a typo? |
Oops. Updated. |
[LGTM Timeline notifier]Timeline:
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: you06 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
TryResolvePolicy PrewriteEncounterLockPolicy = iota | ||
// NoResolvePolicy means do not resolve, but return write conflict errors directly. | ||
// This can be used to let the upper layer choose to retry in pessimistic mode. | ||
NoResolvePolicy |
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.
What is the specific design for using the policy at the upper layer? Is it that autocommit optimistic transactions use NoResolvePolicy
while everything else remains unchanged?
The PR allows the upper layer to control what to do when prewrite encounters lock. A typical usage is for TiDB optimistic autocommit transactions in high-contention scenarios. TiDB will retry the statement in pessimistic mode, so an error can be directly returned to save the effort of backoff, improving efficiency and latency.
A sysbench update_non_index with pareto distribution shows the difference:
If we choose to skip resolving locks when prewrite encounters locks
Master (try resolving locks)