Wrong Result from Tiflash when process Time
Open
Nobody has claimed this yet.
affects-8.4
affects-8.5
component/compute
severity/moderate
type/bug
- Dominant language
- C++
- Stars
- 1k
- Forks
- 423
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 24
Description
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
Drop table if exists t1;
CREATE TABLE t1 (
id INT PRIMARY KEY AUTO_INCREMENT,
col1 TIME DEFAULT NULL
);
insert into t1 values(1, '838:59:59');
insert into t1 values(2, '-838:59:59');
insert into t1 values(3, '0');
ALTER TABLE t1 SET TIFLASH REPLICA 1;
2. What did you expect to see? (Required)
I find that the returned information is inconsistent across two queries.
3. What did you see instead (Required)
mysql> SELECT /*+ READ_FROM_STORAGE(TIFLASH[t1]) */
-> id,
-> col1,
-> ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) AS updated_col1,
-> CASE
-> WHEN ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NULL THEN 'NULL VALUE'
-> ELSE 'VALID VALUE'
-> END AS value_status,
-> LENGTH(col1) AS col1_length,
-> CONCAT(ADDDATE(col1, INTERVAL 12 HOUR_MINUTE), ' processed') AS processed_value
-> FROM
-> t1
-> WHERE
-> ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NOT NULL;
+----+------------+--------------+--------------+-------------+----------------------+
| id | col1 | updated_col1 | value_status | col1_length | processed_value |
+----+------------+--------------+--------------+-------------+----------------------+
| 1 | 838:59:59 | 839:09:59 | VALID VALUE | 9 | 839:11:59 processed |
| 2 | -838:59:59 | -838:49:59 | VALID VALUE | 10 | -838:47:59 processed |
| 3 | 00:00:00 | 00:12:00 | VALID VALUE | 8 | 00:12:00 processed |
+----+------------+--------------+--------------+-------------+----------------------+
3 rows in set (0.04 sec)
mysql> SELECT /*+ READ_FROM_STORAGE(TIKV[t1]) */
-> id,
-> col1,
-> ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) AS updated_col1,
-> CASE
-> WHEN ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NULL THEN 'NULL VALUE'
-> ELSE 'VALID VALUE'
-> END AS value_status,
-> LENGTH(col1) AS col1_length,
-> CONCAT(ADDDATE(col1, INTERVAL 12 HOUR_MINUTE), ' processed') AS processed_value
-> FROM
-> t1
-> WHERE
-> ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NOT NULL;
+----+------------+--------------+--------------+-------------+----------------------+
| id | col1 | updated_col1 | value_status | col1_length | processed_value |
+----+------------+--------------+--------------+-------------+----------------------+
| 2 | -838:59:59 | -838:47:59 | VALID VALUE | 10 | -838:47:59 processed |
| 3 | 00:00:00 | 00:12:00 | VALID VALUE | 8 | 00:12:00 processed |
+----+------------+--------------+--------------+-------------+----------------------+
2 rows in set, 1 warning (0.04 sec)
4. What is your TiDB version? (Required)
TiDB v8.4.0
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the supplied SQL reproduction with READ_FROM_STORAGE(TIFLASH[t1]) and READ_FROM_STORAGE(TIKV[t1]) against TiDB v8.4.0, focusing on TIME values near the documented range limits. Compare returned rows, calculated values, and warnings; the issue is complete when the two storage paths handle these inputs consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, sql
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100