List:Internals« Previous MessageNext Message »
From:Zardosht Kasheff Date:October 22 2010 2:45pm
Subject:Re: [feedback/review request] Re: index creation and concurrent reads
View as plain text  
Yes, we are in agreement here.

On Fri, Oct 22, 2010 at 10:27 AM, Davi Arnaut <davi.arnaut@stripped> wrote:
> 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