diff options
author | Dmitry Lenev <Dmitry.Lenev@oracle.com> | 2010-11-19 10:26:09 +0300 |
---|---|---|
committer | Dmitry Lenev <Dmitry.Lenev@oracle.com> | 2010-11-19 10:26:09 +0300 |
commit | b019ba2f47e7cfef2add56824938953effecff4a (patch) | |
tree | 4e0486b07de2f5676e27e519f22a1d83606f94c8 /mysql-test/r/partition_innodb.result | |
parent | 2d773c8b3ac5a576c9b1e3ed455cad8328711796 (diff) | |
download | mariadb-git-b019ba2f47e7cfef2add56824938953effecff4a.tar.gz |
Fix for bug #57985 "ONLINE/FAST ALTER PARTITION can fail and
leave the table unusable".
Failing ALTER statement on partitioned table could have left
this table in an unusable state. This has happened in cases
when ALTER was executed using "fast" algorithm, which doesn't
involve copying of data between old and new versions of table,
and the resulting new table was incompatible with partitioning
function in some way.
The problem stems from the fact that discrepancies between new
table definition and partitioning function are discovered only
when the table is opened. In case of "fast" algorithm this has
happened too late during ALTER's execution, at the moment when
all changes were already done and couldn't have been reverted.
In the cases when "slow" algorithm, which copies data, is used
such discrepancies are detected at the moment new table
definition is opened implicitly when new version of table is
created in storage engine. As result ALTER is aborted before
any changes to table were done.
This fix tries to address this issue by ensuring that "fast"
algorithm behaves similarly to "slow" algorithm and checks
compatibility between new definition and partitioning function
by trying to open new definition after .FRM file for it has
been created.
Long term we probably should implement some way to check
compatibility between partitioning function and new table
definition which won't involve opening it, as this should
allow much cleaner fix for this problem.
Diffstat (limited to 'mysql-test/r/partition_innodb.result')
-rw-r--r-- | mysql-test/r/partition_innodb.result | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/mysql-test/r/partition_innodb.result b/mysql-test/r/partition_innodb.result index 148504bcc8b..525cc439cd1 100644 --- a/mysql-test/r/partition_innodb.result +++ b/mysql-test/r/partition_innodb.result @@ -489,3 +489,31 @@ Warning 1265 Data truncated for column 'b' at row 1 Error 1067 Invalid default value for 'b' SET SESSION sql_mode = @old_mode; DROP TABLE t1; +# +# Bug#57985 "ONLINE/FAST ALTER PARTITION can fail and leave the +# table unusable". +# +DROP TABLE IF EXISTS t1; +CREATE TABLE t1 (a bigint not null, b int not null, PRIMARY KEY (a)) +ENGINE = InnoDB PARTITION BY KEY(a) PARTITIONS 2; +INSERT INTO t1 values (0,1), (1,2); +# The below ALTER should fail. It should leave the +# table in its original, non-corrupted, usable state. +ALTER TABLE t1 ADD UNIQUE KEY (b); +ERROR HY000: A UNIQUE INDEX must include all columns in the table's partitioning function +# The below statements should succeed, as ALTER should +# have left table intact. +SHOW CREATE TABLE t1; +Table Create Table +t1 CREATE TABLE `t1` ( + `a` bigint(20) NOT NULL, + `b` int(11) NOT NULL, + PRIMARY KEY (`a`) +) ENGINE=InnoDB DEFAULT CHARSET=latin1 +/*!50100 PARTITION BY KEY (a) +PARTITIONS 2 */ +SELECT * FROM t1; +a b +1 2 +0 1 +DROP TABLE t1; |