Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.0, 13.1, 13.2
Description
Likely cause: old code in prep_alter_part_table(), not a recent change. The "Found a row in wrong partition" error comes from a check that the fix for MDEV-20498 added. On CS 10.10.0, which does not have that check, this testcase crashes a debug build with an assertion.
--source include/have_partition.inc
|
--source include/have_sequence.inc
|
CREATE TABLE t1 (a INT) PARTITION BY LINEAR HASH (a) PARTITIONS 9; |
INSERT INTO t1 VALUES (1),(2),(3),(4),(5),(6),(7),(8),(9); |
--error 0,ER_ROW_IN_WRONG_PARTITION
|
ALTER TABLE t1 COALESCE PARTITION 7; |
if ($mysql_errno) |
{
|
--die Reducing a LINEAR HASH table from 9 to 2 partitions fails with "Found a row in wrong partition", although every row is in its right partition |
}
|
CREATE TABLE t2 (a INT) PARTITION BY LINEAR KEY (a) PARTITIONS 17; |
INSERT INTO t2 SELECT seq FROM seq_1_to_100; |
--error 0,ER_ROW_IN_WRONG_PARTITION
|
ALTER TABLE t2 COALESCE PARTITION 13; |
if ($mysql_errno) |
{
|
--die Reducing a LINEAR KEY table from 17 to 4 partitions fails with "Found a row in wrong partition", although every row is in its right partition |
}
|
DROP TABLE t1, t2; |
Leads to:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 06/10/2026 |
mysqltest: At line 9: Reducing a LINEAR HASH table from 9 to 2 partitions fails with "Found a row in wrong partition", although every row is in its right partition
|
The ALTER TABLE gives ERROR 1863 (HY000): Found a row in wrong partition (2 != 1) a:3, and the error log reports the table as corrupted. Before and after the ALTER TABLE, CHECK TABLE gives OK and COUNT(*) is 9. COALESCE PARTITION in two steps (9 to 4 to 2) works. Run alone, the LINEAR KEY check on t2 fails the same way. Other counts fail too, for example 17 to 2 up to 7, and 33 to 2 up to 15. InnoDB gives the same result. Plain HASH and KEY partitioning are not affected. Debug builds give the same result.
With ALTER TABLE t1 COALESCE PARTITION 7, MySQL gives:
|
MySQL |
+--------+--------+--------------------------------+
|
| MySQL | Engine | 9 to 2 partitions |
|
+--------+--------+--------------------------------+
|
| 5.5.62 | InnoDB | works |
|
| 5.5.62 | MyISAM | works |
|
| 5.6.51 | InnoDB | works |
|
| 5.6.51 | MyISAM | server crash, signal 11 |
|
| 5.7.44 | InnoDB | Found a row in wrong partition |
|
| 5.7.44 | MyISAM | Found a row in wrong partition |
|
| 8.0.36 | InnoDB | Found a row in wrong partition |
|
| 9.1.0 | InnoDB | Found a row in wrong partition |
|
+--------+--------+--------------------------------+
|
From the code it seems that in prep_alter_part_table() (sql/sql_partition.cc), start_sec_part= end_sec_part - (lower_2n - (num_parts_remain + 1)) wraps around as a uint when num_parts_remain is below lower_2n / 2. The second range then marks no partition, so a remaining partition that receives rows from a dropped one is not opened for writing.
Attachments
Issue Links
- relates to
-
-
- Closed
-
