From: Zardosht Kasheff Date: October 25 2010 2:55pm Subject: Re: [feedback/review request] Re: index creation and concurrent reads List-Archive: http://lists.mysql.com/internals/38165 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 InnoDB. Is my understanding correct? Thanks -Zardosht On Mon, Oct 25, 2010 at 6:45 AM, Sergey Vojtovich wrote: > Hi Zardosht, Davi, > > answers are in bugdb: > http://bugs.mysql.com/bug.php?id=3D42230 > > 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 w= rote: >> > 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 probl= em. >> > Anyway, who tells whether alter table needs a exclusive metadata lock = is the >> > engine. Alter table uses the handler methods check_if_incompatible_dat= a and >> > alter_table_flags to verify if the change involves only metadata and a= nd 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 ne= ed to >> > copy over the the table data. For example, InnoDB's online index add i= s a >> > "metadata only" operation. Eventually, for both cases, a exclusive met= adata >> > 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 th= e >> > 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, blockin= g >> >> 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 c= ould >> > 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: =A0 =A0http://lists.mysql.com/internals?unsub=3Dsvoj@sun= .com >> > > -- > Sergey Vojtovich > MySQL AB, Software Engineer > Izhevsk, Russia, www.mysql.com >