Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4.0, 10.5, 10.6, 10.11, 11.2(EOL), 11.4, 11.6(EOL)
-
None
Description
In the following test case, the result of the first SELECT is written into the query cache, and the second one uses the query cache, which makes it return a result set, while it shouldn't, because the variable value has changed.
It started happening after this commit in 10.4.0:
commit de745ecf29721795710910a19bd0ea3389da804c |
Author: Oleksandr Byelkin
|
Date: Tue May 22 19:08:39 2018 +0200 |
|
|
MDEV-11953: support of brackets in UNION/EXCEPT/INTERSECT operations |
According to a preliminary discussion on slack, the change wasn't intentional.
set @qc.save= @@global.query_cache_type; |
set global query_cache_type=1; |
set query_cache_type=1; |
|
|
create table t (a int); |
insert into t values (1); |
set @x=1; |
select sql_cache * from t where a=@x; |
set @x=2; |
select sql_cache * from t where a=@x; |
|
|
# Cleanup
|
drop table t; |
set global query_cache_type= @qc.save; |
|
10.5 4955f6018a1af8cbaf491c22f8da7cde56321ba0 |
create table t (a int); |
insert into t values (1); |
set @x=1; |
select sql_cache * from t where a=@x; |
a
|
1
|
set @x=2; |
select sql_cache * from t where a=@x; |
a
|
1
|
Attachments
Issue Links
- is caused by
-
MDEV-11953 support of brackets (parentheses) in UNION/EXCEPT/INTERSECT operations
-
- Closed
-