Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.6.5
Description
When something goes wrong during IMPORT TABLESPACE, the table can be dropped, but n
MariaDB [test]> ALTER TABLE t2 IMPORT TABLESPACE;
|
ERROR 1808 (HY000): Schema mismatch (Number of columns don't match, table has 6 columns but the tablespace meta-data file has 7 columns)
|
|
MariaDB [test]> DROP TABLE t2;
|
Query OK, 0 rows affected (0.004 sec)
|
|
MariaDB [test]> CREATE TABLE t2(id int primary key);
|
ERROR 1005 (HY000): Can't create table `test`.`t2` (errno: 184 "Tablespace already exists")
|
Problem is that the tablespace was still detached after the failed ALTER, as the new tablespace file did not match, and the old was already gone.
After removing the t2.ibd file manually CREATE works again.
But I think it would be better if either:
- even on failed import the table "remembers" the failed import attempt, and keeps the .ibd file somewhat linked to the table so that it gets removed on drop (or just brute force delete .ibd file always)
- let the DROP fail with an appropriate error message if table is in DISCARD stage and an .ibd file by its name is still visible
Attachments
Issue Links
- is caused by
-
MDEV-25506 Atomic DDL: .frm file is removed and orphan InnoDB tablespace is left behind upon crash recovery
- Closed
- relates to
-
MDEV-11658 Simpler, faster IMPORT of InnoDB tables
- Open