-
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
*: Log SQL statement when coprocessor encounteres lock #27735
*: Log SQL statement when coprocessor encounteres lock #27735
Conversation
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
…tmt-on-cop-error
util/trxevents/trx_events.go
Outdated
// TransactionEvent represents a transaction event that may belong to any of the possible types. | ||
type TransactionEvent struct { | ||
eventType EventType | ||
ptr unsafe.Pointer |
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.
Why we have to use unsafe.Pointer
here? (I don't know which one is better, unsafe.Pointer
or interface{}
)
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 either can be used, but interface{} looks better. I thought about avoiding the RTTI (though I'm not sure if there is) but I think perhaps that's a bad idea. I'll change it to interface{} then, please wait a minute
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.
Just a small question. Rest LGTM
@longfangsong: Thanks for your review. The bot only counts approvals from reviewers and higher roles in list, but you're still welcome to leave your comments. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
|
/merge |
/run-check_dev_2 |
1 similar comment
/run-check_dev_2 |
cherry pick to release-5.2 in PR #27924 |
cherry pick to release-5.1 in PR #27925 |
cherry pick to release-4.0 in PR #27926 |
cherry pick to release-5.0 in PR #27927 |
Signed-off-by: ti-srebot <[email protected]>
Signed-off-by: ti-srebot <[email protected]>
Signed-off-by: ti-srebot <[email protected]>
Signed-off-by: ti-srebot <[email protected]>
What problem does this PR solve?
Issue Number: close #27718
Problem Summary: The debug log on coprocessor encounters lock doesn't print out the statement, which makes it difficult to know what statement was affected by the lock. This PR tries to add the log.
What is changed and how it works?
What's Changed: Added a callback parameter to the
Send
method ofkv.Client
that accepts a new TransactionEvent object. This avoids to pass the SQL statement deep down to the coprocessor client part. And I think this callback and events can also be reused by Lock View.How it Works:
Check List
Tests
Side effects
Documentation
Release note