Re: [feedback/review request] Re: index creation and concurrent reads

[Sergey Vojtovich]

Hi Zardosht, Davi,

answers are in bugdb:
http://bugs.mysql.com/bug.php?id=42230

Regards,
Sergey

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