From: Zardosht Kasheff Date: October 22 2010 2:45pm Subject: Re: [feedback/review request] Re: index creation and concurrent reads List-Archive: http://lists.mysql.com/internals/38163 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Yes, we are in agreement here. On Fri, Oct 22, 2010 at 10:27 AM, Davi Arnaut 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 >