Details
-
Bug
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
The following scenario occurred during the testing of MDEV-26450:
--source include/have_innodb.inc
|
|
CREATE TABLE t1 (a INT, b VARCHAR(255)) ENGINE=InnoDB; |
INSERT INTO t1 VALUES(0,''); |
let $datadir=`select @@datadir`; |
--copy_file $datadir/test/t1.frm $datadir/test/old.frm
|
ALTER TABLE t1 MODIFY a INT AFTER b; |
FLUSH TABLES;
|
|
--remove_file $datadir/test/t1.frm
|
--move_file $datadir/test/old.frm $datadir/test/t1.frm
|
|
CHECK TABLE t1; |
OPTIMIZE TABLE t1; |
DROP TABLE t1; |
Starting with MariaDB 10.4, this should crash in an assertion failure during OPTIMIZE TABLE.
10.6 b740b2356d539a27f8a7a9e9b6455f31bc6c9196 |
mariadbd: /mariadb/10.6m/storage/innobase/row/row0sel.cc:2903: void row_sel_field_store_in_mysql_format_func(byte *, const mysql_row_templ_t *, const dict_index_t *, ulint, const byte *, ulint): Assertion `templ->mysql_col_len == len' failed.
|
But, already before that, we have the problem that CHECK TABLE is not reporting any mismatch in the column names and data types between the SQL layer and the InnoDB data dictionary.
Attachments
Issue Links
- relates to
-
MDEV-26450 Corruption due to innodb_undo_log_truncate
- Closed