-
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
session, statistics, util: fix data race of Handle.mu.ctx #33732
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. |
/cc @chrysan @hawkingrei |
/cc @tiancaiamao |
if err != nil { | ||
return nil, nil, errors.Trace(err) | ||
} | ||
defer h.pool.Put(se) |
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.
Should we put this line before the if
check?
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.
IMO we should check error first. According to the implementation of (*sessionPool).Get
, if the returned err
is not nil, then the returned se
must be nil. Besides, in the following code we also check error first and then do the Put operation.
Lines 1713 to 1765 in 37d86da
func (s *session) getInternalSession(execOption sqlexec.ExecOption) (*session, func(), error) { | |
tmp, err := s.sysSessionPool().Get() | |
if err != nil { | |
return nil, nil, errors.Trace(err) | |
} | |
se := tmp.(*session) | |
// The special session will share the `InspectionTableCache` with current session | |
// if the current session in inspection mode. | |
if cache := s.sessionVars.InspectionTableCache; cache != nil { | |
se.sessionVars.InspectionTableCache = cache | |
} | |
if ok := s.sessionVars.OptimizerUseInvisibleIndexes; ok { | |
se.sessionVars.OptimizerUseInvisibleIndexes = true | |
} | |
prePruneMode := se.sessionVars.PartitionPruneMode.Load() | |
if execOption.SnapshotTS != 0 { | |
se.sessionVars.SnapshotInfoschema, err = getSnapshotInfoSchema(s, execOption.SnapshotTS) | |
if err != nil { | |
return nil, nil, err | |
} | |
if err := se.sessionVars.SetSystemVar(variable.TiDBSnapshot, strconv.FormatUint(execOption.SnapshotTS, 10)); err != nil { | |
return nil, nil, err | |
} | |
} | |
prevStatsVer := se.sessionVars.AnalyzeVersion | |
if execOption.AnalyzeVer != 0 { | |
se.sessionVars.AnalyzeVersion = execOption.AnalyzeVer | |
} | |
// for analyze stmt we need let worker session follow user session that executing stmt. | |
se.sessionVars.PartitionPruneMode.Store(s.sessionVars.PartitionPruneMode.Load()) | |
return se, func() { | |
se.sessionVars.AnalyzeVersion = prevStatsVer | |
if err := se.sessionVars.SetSystemVar(variable.TiDBSnapshot, ""); err != nil { | |
logutil.BgLogger().Error("set tidbSnapshot error", zap.Error(err)) | |
} | |
se.sessionVars.SnapshotInfoschema = nil | |
if !execOption.IgnoreWarning { | |
if se != nil && se.GetSessionVars().StmtCtx.WarningCount() > 0 { | |
warnings := se.GetSessionVars().StmtCtx.GetWarnings() | |
s.GetSessionVars().StmtCtx.AppendWarnings(warnings) | |
} | |
} | |
se.sessionVars.PartitionPruneMode.Store(prePruneMode) | |
se.sessionVars.OptimizerUseInvisibleIndexes = false | |
se.sessionVars.InspectionTableCache = nil | |
s.sysSessionPool().Put(tmp) | |
}, 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.
Should all internal sql executions using internal session pools ignore warnings?
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.
Currently we don't check warnings when executing internal sql through (*Handle).execRestrictedSQL
, (*Handle).execRestrictedSQLWithStatsVer
and (*Handle).execRestrictedSQLWithSnapshot
. Maybe we can ignore warnings for now and make improvements if later warnings are needed.
Code Coverage Details: https://codecov.io/github/pingcap/tidb/commit/31822f127d5c7ebcf5366acbab2e73d8dcb250a6 |
/cc @winoros |
/cc @time-and-fate |
return h.withRestrictedSQLExecutor(ctx, func(ctx context.Context, exec sqlexec.RestrictedSQLExecutor) ([]chunk.Row, []*ast.ResultField, error) { | ||
return exec.ExecRestrictedSQL(ctx, []sqlexec.OptionFuncAlias{sqlexec.ExecOptionUseCurSession}, sql, params...) |
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 that we can decouple/detach execRestrictedSQL
from Handle
thoroughly in the future.
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
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 6f2e509
|
Signed-off-by: ti-srebot <[email protected]>
cherry pick to release-6.0 in PR #33919 |
TiDB MergeCI notify🟠 Bad News! New failing [1] after this pr merged.
|
What problem does this PR solve?
Issue Number: close #32867 #33001 #32822
Problem Summary:
We call
(*Handle).execRestrictedSQL
concurrently, which usesHandle.mu.ctx
to fetch another session from session pool to execute internal SQL.tidb/statistics/handle/handle.go
Lines 132 to 134 in bd8c710
However, the method may cause data race in the following code.
tidb/session/session.go
Lines 1748 to 1764 in bd8c710
At Line 1757, we append warnings for
Handle.mu.ctx
, which causes data race.What is changed and how it works?
IMO it is better to make
(*Handle).execRestrictedSQL
inrelevant withHandle.mu.ctx
.Check List
Tests
Side effects
Documentation
Release note