Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL)
-
None
Description
Table corruption reported for versioned partitioned table after DELETE: "Found a misplaced row"
--source include/have_partition.inc
|
|
CREATE TABLE t1 (a INT) WITH SYSTEM VERSIONING PARTITION BY system_time LIMIT 3 (PARTITION p1 HISTORY, PARTITION p2 HISTORY, PARTITION pn CURRENT); |
INSERT INTO t1 VALUES (1),(2),(3),(4); |
DELETE FROM t1; |
DELETE FROM t1; |
CHECK TABLE t1; |
|
# Cleanup
|
DROP TABLE t1; |
10.3 352e7667 |
CHECK TABLE t1;
|
Table Op Msg_type Msg_text
|
test.t1 check error Found a misplaced row
|
test.t1 check error Partition p1 returned error
|
test.t1 check error Upgrade required. Please do "REPAIR TABLE `t1`" or dump/reload to fix it!
|
All of debug, ASAN, release builds produce the same result.
Reproducible on 10.3-10.5 with at least InnoDB, MyISAM, Aria.
Attachments
Issue Links
- causes
-
MDEV-25552 system versioned partitioned by LIMIT tables break CHECK TABLE
- Closed
- relates to
-
MDEV-21358 Implement CHECK for history partitions rotated by LIMIT
- Open
-
MDEV-21641 CHECK reports a misplaced row on partitioned table after dropping versioning
- Closed
-
MDEV-22413 Server hangs upon UPDATE/DELETE on a view reading from versioned partitioned table
- Closed
-
MDEV-33125 CHECK TABLE does not recognize corruption after EXCHANGE WITHOUT VALIDATION on system-time partitioning
- Closed