Comment 2 for bug 1113388

Initial structure of table E

CREATE TABLE E (
                        pk INTEGER AUTO_INCREMENT,
                        col_int_nokey INTEGER /*! NULL */,
                        col_int_key INTEGER /*! NULL */,

                        col_date_key DATE /*! NULL */,
                        col_date_nokey DATE /*! NULL */,

                        col_time_key TIME /*! NULL */,
                        col_time_nokey TIME /*! NULL */,

                        col_datetime_key DATETIME /*! NULL */,
                        col_datetime_nokey DATETIME /*! NULL */,

                        col_varchar_key VARCHAR(1) /*! NULL */,
                        col_varchar_nokey VARCHAR(1) /*! NULL */,

                        PRIMARY KEY (pk),
                        KEY (col_int_key),
                        KEY (col_date_key),
                        KEY (col_time_key),
                        KEY (col_datetime_key),
                        KEY (col_varchar_key, col_int_key)
                ) ENGINE=InnoDB

I don't have logs from the exact reported crash, but in a very similar one the crash happened on the very first ALTER TABLE E ADD COLUMN, so the table definition hadn't yet changed by then.

Same was the case with my intermediate (non-deterministic) MTR test. All it did was

- create table as described above;
- populate with 1000 rows;
- run ALTER TABLE .. ADD COLUMN;
- in parallel with alter, run I_S queries
        SELECT * FROM INFORMATION_SCHEMA . `INNODB_BUFFER_PAGE` LIMIT 1;
        SELECT * FROM INFORMATION_SCHEMA . `GLOBAL_TEMPORARY_TABLES` LIMIT 1;

I don't know if the first query is anyhow important or it's there just for the right timing, I suspect the latter.

Anyway, it happens easily with the provided grammar, I expect you shouldn't have a problem reproducing it.