unioned query with var_pop over window may lead to incorrect result
#52985
Comments
ti-chi-bot
bot
added
may-affects-5.4
|
/label affects-5.4 |
ti-chi-bot
bot
added
affects-5.4
|
/label affects-6.1 |
|
/label affects-6.5 |
|
/label affects-7.1 |
|
/label affects-7.5 |
|
/assign @SeaRise |
|
Reproduced on a single node, after creating the table and inserting data, wait a while. The result is correct after setting tidb_executor_concurrency to 1, which should be a concurrency issue in TiDB. |
|
Simplified case |
It will get correct result by The |
|
|
|
The But the reusing becomes a problem when the projection is related to union. |
It was found that the aggregation elimination rule introduced an error during the construction of the plan, so I think this is an issue about planner. |
I'm not good at the execution techs. Maybe one way is to introduce copy-on-write for chunk reuse? Then planner don't need to consider this execution option |
@XuHuaiyu What do you think? |
|
Why the first child of union is a |
|
The result could be correct after the following modification. diff --git a/pkg/planner/core/rule_eliminate_projection.go b/pkg/planner/core/rule_eliminate_projection.go
index c323fb20cd..11d4c13925 100644
--- a/pkg/planner/core/rule_eliminate_projection.go
+++ b/pkg/planner/core/rule_eliminate_projection.go
@@ -112,13 +112,17 @@ func doPhysicalProjectionElimination(p base.PhysicalPlan) base.PhysicalPlan {
return p
}
child := p.Children()[0]
- if childProj, ok := child.(*PhysicalProjection); ok {
+ childProj, ok := child.(*PhysicalProjection)
+ if ok {
// when current projection is an empty projection(schema pruned by column pruner), no need to reset child's schema
// TODO: avoid producing empty projection in column pruner.
if p.Schema().Len() != 0 {
childProj.SetSchema(p.Schema())
}
}
+ if proj.AvoidColumnEvaluator {
+ childProj.AvoidColumnEvaluator = true
+ }
for i, col := range p.Schema().Columns {
if p.SCtx().GetSessionVars().StmtCtx.ColRefFromUpdatePlan.Has(int(col.UniqueID)) && !child.Schema().Columns[i].Equal(nil, col) {
return p |
|
related: #19027 |
|
Another approach to fix this issue: |
…ionElimination (pingcap#55219) close pingcap#52985
1. Minimal reproduce step (Required)
Firstly, execute
init.sqlto create the table. Then executingerror.sqlyields unexpected results. Note that reproducing these results might not be entirely stable. Typically, it can be completed within three attempts. You can try executingerror.sqlmultiple times or executeinit.sqlagain to rebuild the table.init.sql.txt
error.sql.txt
2. What did you expect to see? (Required)
The SQL statement consists of a UNION of two queries. The first query has four rows with the first column being respectively
oyz4u,wcnmm,z36ma, andtl. The first column of the second query is a constant string '1'.3. What did you see instead (Required)
In the multi-node version, some results other than '1' are outputted, while the single-node version behaves normally.
output_re_main2.log
output_re_single2.log
4. What is your TiDB version? (Required)
topology:
distributed.yaml:
single.yaml
about us
We are the BASS team from the School of Cyber Science and Technology at Beihang University. Our main focus is on system software security, operating systems, and program analysis research, as well as the development of automated program testing frameworks for detecting software defects. Using our self-developed database vulnerability testing tool, we have identified the above-mentioned vulnerabilities in TiDB that may lead to database logic error.
The text was updated successfully, but these errors were encountered: