List:Internals« Previous MessageNext Message »
From:Zardosht Kasheff Date:October 22 2010 1:40pm
Subject:Re: [feedback/review request] Re: index creation and concurrent reads
View as plain text  
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.
>
>
Thread
Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff24 Jul
  • Re: [feedback/review request] Re: index creation and concurrent readsDavi Arnaut24 Jul
    • Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff24 Jul
      • Re: [feedback/review request] Re: index creation and concurrent readsDavi Arnaut24 Jul
        • Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff24 Jul
    • Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff22 Oct
      • Re: [feedback/review request] Re: index creation and concurrent readsDavi Arnaut22 Oct
        • Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff22 Oct
          • Re: [feedback/review request] Re: index creation and concurrent readsDavi Arnaut22 Oct
            • Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff22 Oct
              • Re: [feedback/review request] Re: index creation and concurrentreadsSergey Vojtovich25 Oct
                • Re: [feedback/review request] Re: index creation and concurrent readsZardosht Kasheff25 Oct
                  • Re: [feedback/review request] Re: index creation and concurrentreadsSergey Vojtovich25 Oct