Open r33s3n6 opened 1 week ago
The root cause is the truncate(0, 309) is NAN now, tmp = 0 * INF, caused NAN, and max(nan, 100) is not stable: if NaN comes first, it is nan; if 100 comes first, it is 100. Not sure if NaN should exist and be taken into consideration. Part of truncate implementation: https://github.com/pingcap/tidb/blob/924784aa3e57db874633eff00f435586eaf05bd8/pkg/types/helper.go#L55-L68
The reason why query without group by c0 is correct is that its plan is different. It has a topN operator under aggreation, while the topN operator chooses 100 instead of NAN:
mysql> explain analyze SELECT max(truncate(truncate(c1, c2), 309)) FROM t1;
+------------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+-----------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+------------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+-----------+------+
| StreamAgg_10 | 1.00 | 1 | root | | time:793.4µs, loops:2, RU:0.497877 | funcs:max(Column#7)->Column#5 | 404 Bytes | N/A |
| └─Projection_21 | 1.00 | 1 | root | | time:787.4µs, loops:2, Concurrency:OFF | truncate(truncate(test.t1.c1, test.t1.c2), 309)->Column#7 | 760 Bytes | N/A |
| └─Projection_19 | 1.00 | 1 | root | | time:780.5µs, loops:2, Concurrency:OFF | test.t1.c1, test.t1.c2 | 1.11 KB | N/A |
| └─TopN_13 | 1.00 | 1 | root | | time:777.1µs, loops:2 | Column#6:desc, offset:0, count:1 | 1.12 KB | N/A |
| └─Projection_20 | 8000.00 | 2 | root | | time:758.8µs, loops:3, Concurrency:5 | test.t1.c1, test.t1.c2, truncate(truncate(test.t1.c1, test.t1.c2), 309)->Column#6 | 9.28 KB | N/A |
| └─Selection_15 | 8000.00 | 2 | root | | time:698.5µs, loops:3 | not(isnull(truncate(truncate(test.t1.c1, test.t1.c2), 309))) | 760 Bytes | N/A |
| └─TableReader_17 | 10000.00 | 2 | root | | time:657µs, loops:3, cop_task: {num: 1, max: 604µs, proc_keys: 2, tot_proc: 64.2µs, tot_wait: 70.3µs, copr_cache_hit_ratio: 0.00, build_task_duration: 13.9µs, max_distsql_concurrency: 1}, rpc_info:{Cop:{num_rpc:1, total_time:577.7µs}} | data:TableFullScan_16 | 285 Bytes | N/A |
| └─TableFullScan_16 | 10000.00 | 2 | cop[tikv] | table:t1 | tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 2, total_process_keys_size: 96, total_keys: 3, get_snapshot_time: 44.8µs, rocksdb: {key_skipped_count: 2, block: {}}}, time_detail: {total_process_time: 64.2µs, total_wait_time: 70.3µs, tikv_wall_time: 273.3µs} | keep order:false, stats:pseudo | N/A | N/A |
+------------------------------------+----------+---------+-----------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------------------------------------------+-----------+------+
/severity major
1. Minimal reproduce step (Required)
2. What did you expect to see? (Required)
result should be 100:
3. What did you see instead (Required)
4. What is your TiDB version? (Required)
topology: distributed.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.