drop primary key sometimes fails

[prohaska]

DROP TABLE IF EXISTS testtable;
CREATE TABLE `testtable` (    
  `id` INT(11) NOT NULL,
  `keyword` VARCHAR(299) DEFAULT NULL,
  PRIMARY KEY (`id`),  
  KEY `keyword` (`keyword`(100))
) ENGINE=TokuDB DEFAULT CHARSET=utf8 ROW_FORMAT=TOKUDB_QUICKLZ;
ALTER TABLE testtable DROP PRIMARY KEY;

Error Code: 1089
Incorrect prefix key; the used key part isn't a string, the used length is longer than the key part, or the storage engine doesn't support unique prefix keys

[prohaska]

mysql> CREATE TABLE `testtable` (       `id` INT(11) NOT NULL,   `keyword` VARCHAR(299) DEFAULT NULL,   PRIMARY KEY (`id`),     KEY `keyword` (`keyword`(100)) ) ENGINE=TokuDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> set tokudb_disable_hot_alter=on;
Query OK, 0 rows affected (0.00 sec)

mysql> ALTER TABLE testtable DROP PRIMARY KEY;
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

[prohaska]

mysql> CREATE TABLE `testtable` (       `id` INT(11) NOT NULL,   `keyword` VARCHAR(299) DEFAULT NULL,   PRIMARY KEY (`id`),     KEY `keyword` (`keyword`(100)) ) ENGINE=TokuDB;
Query OK, 0 rows affected (0.01 sec)

mysql> set tokudb_disable_hot_alter=off;
Query OK, 0 rows affected (0.00 sec)

mysql> ALTER TABLE testtable DROP PRIMARY KEY;
Query OK, 0 rows affected (0.13 sec)
Records: 0  Duplicates: 0  Warnings: 0

[prohaska]

mysql_prepare_create_table gets called twice. the first call is from mysql_inplace_alter_table. the second call is from mysql_alter_table->mysql_compare_tables. unfortunately, mysql_prepare_create_table messes up the column->length (sql_table.cc:3477), so we get this strange error.

[prohaska]

mysql_prepare_create_table is not idempotent; it modifies the alter_info struct. the alter_info struct describes the alter table operation. unfortunately, mysql_prepare_create_table is called on the inlace alter table path, and then again on the slow alter table path if the inplace alter table path can not handle the alter table operation. if it is called twice, erroneous results occur, like the bogus error when dropping the primary key as described in this issue. to fix the problem, a deep copy of the alter_info struct should be used on the inplace alter table code path.