-
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
expression,table: fix insert partitioned table bug when the time zone change #14370
expression,table: fix insert partitioned table bug when the time zone change #14370
Conversation
Hi @tiancaiamao , please update the release note in the PR Description. |
@@ -291,6 +291,9 @@ func (sf *ScalarFunction) Eval(row chunk.Row) (d types.Datum, err error) { | |||
|
|||
// EvalInt implements Expression interface. | |||
func (sf *ScalarFunction) EvalInt(ctx sessionctx.Context, row chunk.Row) (int64, bool, error) { | |||
if f, ok := sf.Function.(builtinFuncNew); ok { | |||
return f.evalIntWithCtx(ctx, row) | |||
} | |||
return sf.Function.evalInt(row) |
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.
For using the context in current session. I think of another way:
How about add a new function setCtx
for struct builtinFunc
,
and change here as:
return sf.Function.evalInt(row) | |
sf.Function.setCtx(ctx) | |
return sf.Function.evalInt(row) |
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 setCtx
way is ugly IMHO. @Deardrops
The real problem is, the session context is not something belongs to a function.
As long as function store the ctx
, the function is invalid when the session context changes.
So the right way to fix the problem is removing ctx
from the struct, instead of providing setCtx
as a workaround.
Co-Authored-By: bb7133 <[email protected]>
In MySQL 8.0, It has same behavior with current TiDB version, does this really a bug?
|
Try this one and verify the result in TiDB and MySQL:
|
TiDB: (master branch)
MySQL 8.0
|
PTAL @bb7133 @XuHuaiyu @Deardrops |
1 similar comment
PTAL @bb7133 @XuHuaiyu @Deardrops |
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
PTAL @Deardrops @XuHuaiyu |
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
/run-all-tests |
/merge |
/run-all-tests |
cherry pick to release-3.0 failed |
What problem does this PR solve?
Create a partitioned table at timezone=X, then change timezone=Y, and insert data, the data doesn't locate in the correct partition.
What is changed and how it works?
The root cause of this bug is that expression should not cache the session context (which contains the timezone information).
When a partitioned table is loaded into memory, the partition expression is computed with the session context at that time.
If we change the session context (timezone) later and still use the partition expression, things would go wrong because expression uses the old session context.
Here for example:
When we're deciding which partition this data should belong to, we calculate the partition expression to get the answer.
The current timezone has already changed, but the partition expression still uses the old timezone.
So the result is wrong and we insert the data to the wrong partition.
Fix the expression is not a easy work. There are too much code involved.
This commit solely fixes the current table partition bug I meet.
We need to refactor a lot of codes to totally solve the problem:
builtinFuncNew
interfaceevalXXXWithCtx
for allbuiltinFuncSig
builtinFunc
withbuiltinFuncNew
ctx
from thebaseBuiltinFunc
structCheck List
Tests
Code changes
Side effects
Related changes
Release note