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

[Sergey Vojtovich]

Zardosht,

On Mon, Oct 25, 2010 at 10:55:45AM -0400, Zardosht Kasheff wrote:
> 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.
It seems they're not available. :(

> 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
> InnoDB.
> 
> Is my understanding correct?
At least that's what we know so far. Davi is working with InnoDB team to
figure out what's going on.

Regards,
Sergey

> Thanks
> -Zardosht
> 
> 
> On Mon, Oct 25, 2010 at 6:45 AM, Sergey Vojtovich
> <sergey.vojtovich@stripped> wrote:
> > 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
> >
> 
> --
> 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