-
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
infoschema: Add ALL_SQL_DIGESTS field to the TIDB_TRX table #24863
Conversation
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
/run-check_dev_2 |
Is the bench command still available? |
Signed-off-by: MyonKeminta <[email protected]>
/run-all-tests |
session/txn.go
Outdated
return | ||
} | ||
|
||
info := txn.txnInfo.GetSnapInfo() |
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.
Though GetSnapInfo
is thread safe, accessing txn.txnInfo
is not, so here's a datarace with txn.txnInfo = info
in storeTxnInfo
.
Can we use atomicTxnInfo
all the time?
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.
onStmtStart is expected to run within the transaction's thread. The purpose I keeps the txnInfo
field is to avoid atomic loading every time it's used, and I expect the txnInfo
is only used within the transaction's thread and the atomicTxnInfo
is only used for fetching information concurrently. Perhaps this is a bad idea. 😕
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.
Ah sorry. I just notice the race reported by CI. It's weird to me that onStmtStart and onStmtEnd is invoked concurrently...
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 test TestAmendForUniqueIndex
in pessimistic_test.go is executing two queries concurrently in a single tk... @cfzjywxk Is this this kind of usage allowed..?
go func() {
var err error
err = tk2.ExecToErr("begin pessimistic")
if err != nil {
errCh <- err
return
}
err = tk2.ExecToErr("insert into t values(5, 5)")
if err != nil {
errCh <- err
return
}
err = tk2.ExecToErr("delete from t where id = 5")
if err != nil {
errCh <- err
return
}
// let commit in tk start.
errCh <- err
time.Sleep(time.Millisecond * 100)
err = tk2.ExecToErr("commit")
errCh <- err
}()
err = <-errCh
c.Assert(err, Equals, nil)
tk.MustExec("commit")
tk2.MustExec("admin check table t")
err = <-errCh
c.Assert(err, Equals, nil)
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's unexpected usage, need to fix.
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
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
[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 writing |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 43cd7b4
|
@MyonKeminta: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. 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. |
/run-unit-test |
/merge |
What's wrong with
|
/merge |
txn.initStmtBuf() | ||
atomic.StoreUint64(&txn.EntriesCount, uint64(txn.Transaction.Len())) | ||
atomic.StoreUint64(&txn.EntriesSize, uint64(txn.Transaction.Size())) | ||
txn.recreateTxnInfo( |
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 atomic? when will the changeInvalidToValid()
function been called concurrently? @MyonKeminta
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 should not be called concurrently, but the content of the txnInfo
may be retrieved by another thread outside the session.
What problem does this PR solve?
Problem Summary:
The
TIDB_TRX
table is part of Lock View , introduced in #22908 . However one of the important fieldsALL_SQLS
is not finished in that PR. This PR adds this field, and also avoidsALL_SQLS
,DIGEST
,State
being inconsistent due to multiple atomic loads.What is changed and how it works?
What's Changed: Makes the TxnInfo struct a hybrid thing of mutable fields (updated with atomic operations) and immutable fields (updated by replacing the whole struct). When updating the SQL Digest, the whole struct will be replaced. However, the other fields that are not so important (len and size) is still loaded by multiple atomic operations. Then the AllSQLs information is added to the struct as an immutable field.
This PR also added more tests.
Related changes
Check List
Tests
Side effects
Release note