with expand_fast_index_creation the restore of secondary keys is not online

[Miguel Angel Nieto]

Let's say you have this table:

> show create table t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE `t` (
  `i` int(11) NOT NULL AUTO_INCREMENT,
  `c` char(10) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`i`),
  KEY `c` (`c`)
) ENGINE=InnoDB AUTO_INCREMENT=17366761 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC

and you enable expand_fast_index_creation.

If you run a not online ALTER like this one:

alter table t force , ROW_FORMAT=DYNAMIC, CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

The table will be locked and this simple UPDATE statement will wait:

> update t set c="przemek" where i=12312;

The problem is that when the "restoring secondary keys" process starts the table remains locked. The restore of secondary keys should be online. So, actually using expand_fast_index_creation locks the table much more time than:

DROP INDEX...
ALTER...
ADD INDEX...

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-3393