MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Sergey Vojtovich Date:December 1 2009 7:43pm
Subject:Re: bzr commit into mysql-5.1-bugteam branch (ramil:3226) Bug#48645
View as plain text  
Hi Ramil,

see comments inline.

On Fri, Nov 27, 2009 at 06:58:48PM +0000, Ramil Kalimullin wrote:
> #At file:///home/ram/mysql/b48645-5.1-bugteam/ based on
> revid:martin.hansson@stripped
> 
>  3226 Ramil Kalimullin	2009-11-27
>       Fix for bug#48645: Dropping an unique key and adding one leads 
>       to a table corruption

...skip...

> === modified file 'sql/sql_table.cc'
> --- a/sql/sql_table.cc	2009-10-27 09:53:16 +0000
> +++ b/sql/sql_table.cc	2009-11-27 18:58:44 +0000

...skip...

> @@ -5780,7 +5794,8 @@ compare_tables(TABLE *table,
>        (*candidate_key_count)++;
>  
>      /* Search a new key with the same name. */
> -    for (new_key= *key_info_buffer; new_key < new_key_end; new_key++)
> +    for (new_key= *key_info_buffer, new_key_number= 0;
> +         new_key < new_key_end; new_key++, new_key_number++)
>      {
>        if (! strcmp(table_key->name, new_key->name))
>          break;
IMHO there is more natural way to fix this. As we require key order to
stay intact, we can remove this loop and compare table_key->name vs
*key_info_buffer[table_key - table->info]. Of course taking into account
that new key array may have less elements.

The same should be done a few lines below, where we look up for added
keys. This way we won't need extra variables and extra loop.

I'm still a bit concerned that in some cases for DROP + ADD, when key
order remains just by a chance, index will not get rebuilt.

What I'm more concerned about is that with these approaches dropping
one of the first indexes will initiate rebuild of all subsequent
indexes, even though storage engine doesn't require it. It'll cause
considerable slowdown for e.g. NDB. :(

I'd suggest to let storage engine to decide if it cares about index
order or not. We could probably do that by adding a new flag for
::check_if_incompatible_data(), or adding new HTON flag.

Regards,
Sergey
-- 
Sergey Vojtovich <svoj@stripped>
MySQL AB, Software Engineer
Izhevsk, Russia, www.mysql.com
Thread
bzr commit into mysql-5.1-bugteam branch (ramil:3226) Bug#48645Ramil Kalimullin27 Nov
  • Re: bzr commit into mysql-5.1-bugteam branch (ramil:3226) Bug#48645Sergey Vojtovich1 Dec
  • Re: bzr commit into mysql-5.1-bugteam branch (ramil:3226) Bug#48645Sergei Golubchik14 Dec