Comment 1 for bug 999147

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote : Re: A crash that leaves behind an InnoDB temporary table with indexes results in an unbootable server

To reproduce, add a new crash injection site at the end of non-error path in ha_innobase::add_index()
 DBUG_EXECUTE_IF("crash_innodb_add_index_after", DBUG_SUICIDE(););

and then run the following test case:

-- source include/not_embedded.inc
-- source include/not_valgrind.inc
-- source include/not_crashrep.inc
-- source include/have_debug.inc
-- source include/have_innodb.inc

--disable_warnings
DROP TABLE IF EXISTS t1;
--enable_warnings

SET SESSION expand_fast_index_creation=ON;

CREATE TEMPORARY TABLE t1 (a INT, b INT, INDEX(a));

--exec echo "restart" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect

SET debug="+d,crash_innodb_add_index_after";
--error 2013
ALTER TABLE t1 ADD INDEX (b);

# Turn on reconnect
--enable_reconnect

# Call script that will poll the server waiting for it to be back online again
--source include/wait_until_connected_again.inc

SHOW TABLES;

The only place in InnoDB that uses temporary indexes is the regular table index creation and drop. This code however is not used for the temporary tables, as they are created anew with the final index definitions and then data is copied.

However the Percona Server expanded index creation might use the regular index creation and drop code path in a corner case with expanded fast index creation enabled: when there is an already-existing secondary index on the table, it will be dropped from the new temp table and recreated after copying the data.