are the worklogs mentioned publicly available? I click on the links
and get nothing. They state that either they are not public or do not
exist. It makes understanding the issues difficult.
But the understanding seems to be this:
InnoDB expects the table to be reopened before index creation, which
is what "wait_while_table_is_used(thd, table, HA_EXTRA_FORCE_REOPEN);"
The fix prevents this line from being called, thus causing a bug in
Is my understanding correct?
On Mon, Oct 25, 2010 at 6:45 AM, Sergey Vojtovich
> Hi Zardosht, Davi,
> answers are in bugdb:
> On Fri, Oct 22, 2010 at 10:45:32AM -0400, Zardosht Kasheff wrote:
>> Yes, we are in agreement here.
>> On Fri, Oct 22, 2010 at 10:27 AM, Davi Arnaut <davi.arnaut@stripped>
>> > 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
>> > 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
>> MySQL Internals Mailing List
>> For list archives: http://lists.mysql.com/internals
>> To unsubscribe: http://lists.mysql.com/internals?unsub=1
> Sergey Vojtovich <svoj@stripped>
> MySQL AB, Software Engineer
> Izhevsk, Russia, www.mysql.com