This is the bug #42230 that is filed.
in mysql_alter_table, we have the following code:
if (new_table && !(new_table->file->ha_table_flags() &
/* We don't want update TIMESTAMP fields during ALTER TABLE. */
thd_proc_info(thd, "copy to tmp table");
error= copy_data_between_tables(table, new_table,
order_num, order, &copied, &deleted,
wait_while_table_is_used(thd, table, HA_EXTRA_FORCE_REOPEN);
thd_proc_info(thd, "manage keys");
error= ha_autocommit_or_rollback(thd, 0);
For engines that do not implement add_index, new_table is true and
copy_data_between_tables is called, and wait_while_table_is_used is
not called. Queries may be run on the table while
copy_data_between_tables is being run (a very very long operation).
For engines that do implement add_index, new_table is false, the
'else' clause is run, and wait_while_table_is_used is called, blocking
out all queries.
On Fri, Oct 22, 2010 at 9:32 AM, Davi Arnaut <davi.arnaut@stripped> wrote:
> On 10/22/10 12:24 AM, Zardosht Kasheff wrote:
>> To recap, the problem is the following: for storage engines that do
>> NOT implement handler::add_index, users can query a table while
>> another thread is adding an index. For storage engines that DO
> Where do you take this from?
>> implement handler::add_index, queries block until index creation
>> completes. This is a bug I would very much like to fix.
> This does not match the description in WL#1563.