Skip to content
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

some SQL result is not the same when enable/disable plancache #47008

Closed
lcwangchao opened this issue Sep 15, 2023 · 2 comments · Fixed by #47072
Closed

some SQL result is not the same when enable/disable plancache #47008

lcwangchao opened this issue Sep 15, 2023 · 2 comments · Fixed by #47072
Assignees
Labels
severity/moderate sig/planner SIG: Planner type/bug The issue is confirmed as a bug.

Comments

@lcwangchao
Copy link
Collaborator

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

In a session without plancache

set @@tidb_enable_prepared_plan_cache=0;
set @@time_zone='UTC';
set @@collation_connection='utf8_general_ci';
prepare s from 'select DATE_FORMAT("2020-01-01","%W") = "wednesday"';
execute s; -- output 1
set @@collation_connection='utf8_bin';
execute s; -- output 0

In a session with plancache

set @@tidb_enable_prepared_plan_cache=1;
set @@time_zone='UTC';
set @@collation_connection='utf8_general_ci';
prepare s from 'select DATE_FORMAT("2020-01-01","%W") = "wednesday"';
execute s; -- output 1
set @@collation_connection='utf8_bin';
execute s; -- output 1

2. What did you expect to see? (Required)

The second execute should output a same value not matter tidb_enable_prepared_plan_cache is on or off

3. What did you see instead (Required)

The output of the second execute is not the same for different tidb_enable_prepared_plan_cache value

4. What is your TiDB version? (Required)

master

@lcwangchao lcwangchao added type/bug The issue is confirmed as a bug. sig/planner SIG: Planner severity/moderate labels Sep 15, 2023
@lcwangchao
Copy link
Collaborator Author

I think the reason is the expression is computing it's collation using session collation here:

charsetInfo, collation := ctx.GetSessionVars().GetCharsetInfo()

But when the collation of session changes, the cached plan still uses the old value.

@qw4990 qw4990 self-assigned this Sep 18, 2023
@qw4990
Copy link
Contributor

qw4990 commented Sep 18, 2023

It seems like we should consider connection's charset when hitting the plan cache:
image

I'll fix it this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/moderate sig/planner SIG: Planner type/bug The issue is confirmed as a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants