Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
N/A
-
None
Description
If table creation fails due to an atomic_write-related problem, the failed CREATE statement leaves an orphan .ibd file behind, which is not easy to get rid of, apart from removing it from the file system:
MariaDB [test]> create table t1 (i int) engine=InnoDB atomic_writes=off; |
ERROR 1005 (HY000): Can't create table `test`.`t1` (errno: -1 "Internal error < 0 (Not system error)") |
MariaDB [test]> system ls -l data/test/
|
-rw-rw---- 1 elenst elenst 0 Apr 11 01:48 t1.ibd
|
MariaDB [test]> show tables;
|
Empty set (0.00 sec)
|
|
|
MariaDB [test]> create table t1 (i int);
|
ERROR 1813 (HY000): Tablespace for table '`test`.`t1`' exists. Please DISCARD the tablespace before IMPORT. |
MariaDB [test]> alter table t1 discard tablespace;
|
ERROR 1146 (42S02): Table 'test.t1' doesn't exist |
Attachments
Activity
revno: 3973
committer: Jan Lindström <jplindst@mariadb.org>
branch nick: 10.0-FusionIO2
timestamp: Wed 2014-04-16 16:55:36 +0300
message:
MDEV-6070: FusionIO: Failure to create a table with ATOMIC_WRITES
option leaves the database in inconsistent state,
Analysis: Problem was that atomic writes variable had incorrect
type on same places leading to fact that e.g. OFF option was
not regognized. Furthermore, some error check code was missing
from both InnoDB and XtraDB engines. Finally, when table is
created we have already created the .ibd file and if we can't
set atomic writes it stays there.
Fix: Fix atomic writes variable type to ulint as it should be.
Fix: Add proper error code checking on os errors on both InnoDB
and XtraDB
Fix: Remove the .idb file when atomic writes can't be enabled
to a new table.
Additional problem (this should work on all file systems):
MariaDB [test]> CREATE TABLE t6 (i int) ENGINE=InnoDB ATOMIC_WRITES=OFF;ERROR 1005 (HY000): Can't create table `test`.`t6` (errno: -1 "Internal error < 0 (Not system error)")