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() &
HA_NO_COPY_ON_ALTER))
{
/* We don't want update TIMESTAMP fields during ALTER TABLE. */
new_table->timestamp_field_type= TIMESTAMP_NO_AUTO_SET;
new_table->next_number_field=new_table->found_next_number_field;
thd_proc_info(thd, "copy to tmp table");
error= copy_data_between_tables(table, new_table,
alter_info->create_list, ignore,
order_num, order, &copied, &deleted,
alter_info->keys_onoff,
alter_info->error_if_not_empty);
}
else
{
VOID(pthread_mutex_lock(&LOCK_open));
wait_while_table_is_used(thd, table, HA_EXTRA_FORCE_REOPEN);
VOID(pthread_mutex_unlock(&LOCK_open));
thd_proc_info(thd, "manage keys");
alter_table_manage_keys(table, table->file->indexes_are_disabled(),
alter_info->keys_onoff);
error= ha_autocommit_or_rollback(thd, 0);
if (end_active_trans(thd))
error= 1;
}
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.
-Zardosht
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.
>
>
