From: Zardosht Kasheff Date: October 22 2010 1:40pm Subject: Re: [feedback/review request] Re: index creation and concurrent reads List-Archive: http://lists.mysql.com/internals/38161 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 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. > >