Re: possible bug in the 5.6.6 alter inplace software
Rich Prohaska <[email protected]> Tue, 10 Jul 2012 14:59:46 -0400
| Newsgroups | gmane.comp.db.mysql.devel |
|---|---|
| Message-ID | <CAB3YYRVbEcu9vpQvim9eyB-hL2erwt96-BpwJPaD8WzojTWEqw@mail.gmail.com> |
Hello Dmitry, I finally understand that you created a simpler test case than mine that exhibits the problem. Thanks Rich Prohaska On Tue, Jul 10, 2012 at 12:00 PM, Rich Prohaska <[email protected]> wrote: > Hello Dmitry, > My example may have the same result (table copied) but the cause is > different (new columns are being added to the table, yet the fill > function sets the ADD and DROP flags). > > On Tue, Jul 10, 2012 at 11:31 AM, Dmitry Lenev <[email protected]> wrote: >> Hello Rich! >> >> Thanks for finding and reporting this issue! >> >> * Rich Prohaska <[email protected]> [12/07/10 18:11]: >>> Hello, >>> >>> We found a alter table statement that adds columns to a table sets the >>> ADD and DROP INDEX flags in the alter inplace info struct. When >>> running the attached mysql test program, innodb's >>> check_if_supported_inplace_alter gets called with unexpected >>> handler_flags set (handler_flags = 2115 = ADD_INDEX + DROP_INDEX + >>> ADD_COLUMN + ALTER_COLUMN_ORDER). The fill_if_supported_inplace_alter >>> function is probably at fault. We are using >>> mysql-5.6.6-labs-june-2012. >> >> Indeed, this is a bug in fill_alter_inplace_info() code. >> This function incorrectly determines prefix keys as dropped >> and then re-created by any ALTER TABLE. :( >> >> I have reported a bug about it: http://bugs.mysql.com/65865. >> >> Thanks once again! >> >> Best regards, >> Dmitry Lenev >> >> -- >> Dmitry Lenev, Software Developer >> Oracle Development SPB/MySQL, www.mysql.com >> >> Are you MySQL certified? http://www.mysql.com/certification -- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe: http://lists.mysql.com/internals