List:Internals« Previous MessageNext Message »
From:Davi Arnaut Date:October 22 2010 2:27pm
Subject:Re: [feedback/review request] Re: index creation and concurrent reads
View as plain text  
On 10/22/10 11:40 AM, Zardosht Kasheff wrote:
> This is the bug #42230 that is filed.
>

[..]

>
> 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

This is a oversimplification, it does not help to understand the 
problem. Anyway, who tells whether alter table needs a exclusive 
metadata lock is the engine. Alter table uses the handler methods 
check_if_incompatible_data and alter_table_flags to verify if the change 
involves only metadata and and if online index operations are supported.

> not called. Queries may be run on the table while
> copy_data_between_tables is being run (a very very long operation).

If copy_data_between_tables is called, it means that the table data is 
also going to be changed. If only metadata is being changed, there is no 
need to copy over the the table data. For example, InnoDB's online index 
add is a "metadata only" operation. Eventually, for both cases, a 
exclusive metadata lock is always needed because the FRM needs to be 
modified. If we are changing only metadata, this exclusive lock is taken 
early as later the table will be renamed. If data is being changed, the 
exclusive lock is delayed to after the table data has been copied.

> 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.

For your engine, data needs to be copied over to a new table on index 
add? If not, its a metadata only change and exclusive lock is taken 
because we are only going to modify the table metadata (frm).

The point is that it seems that this exclusive lock shouldn't be taken 
so early (and this would be the regression introduced by Bug#24395) and 
could be delayed to after add/drop_index. But Vojtovich claims that 
there is code relying on this exclusive lock that is taken early. So we 
need to wait him to identify which code is this.

Regards,

Davi
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