Merge lp:~akopytov/percona-server/bugs-1039536-1081003-5.1 into lp:percona-server/5.1
Status: | Merged |
---|---|
Approved by: | Laurynas Biveinis |
Approved revision: | no longer in the source branch. |
Merged at revision: | 501 |
Proposed branch: | lp:~akopytov/percona-server/bugs-1039536-1081003-5.1 |
Merge into: | lp:percona-server/5.1 |
Diff against target: |
339 lines (+222/-35) 3 files modified
Percona-Server/client/mysqldump.c (+108/-35) Percona-Server/mysql-test/r/percona_mysqldump_innodb_optimize_keys.result (+74/-0) Percona-Server/mysql-test/t/percona_mysqldump_innodb_optimize_keys.test (+40/-0) |
To merge this branch: | bzr merge lp:~akopytov/percona-server/bugs-1039536-1081003-5.1 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Laurynas Biveinis (community) | Approve | ||
Review via email: mp+135091@code.launchpad.net |
Description of the change
Bug #1039536: mysqldump --innodb-
table definitions
Bug #1081003: mysqldump --innodb-
The problem in bug #1039536 was that mysqldump --innodb-
did not handle composite indexes correctly when verifying if the
optimization is applicable with respect to AUTO_INCREMENT columns. When
an AUTO_INCREMENT column was encountered in the SHOW CREATE TABLE
output, the column was marked so that subsequent index specifications
involving that column would not be used in deferred index creation
mechanism, as MySQL does not allow creating tables with unindexed
AUTO_INCREMENT columns. However, the code checking if an index
specification involves a previously marked AUTO_INCREMENT column failed
to handle composite keys correctly, so those keys were optimized away
resulting in an invalid table definition.
A closely related problem in bug #1081003 was that even in cases where
indexes with AUTO_INCREMENT columns where correctly detected, mysqldump
prevented all such keys from optimization, even though it is sufficient
to skip just one (e.g. the first one).
Fixed by refactoring the AUTO_INCREMENT handling code in mysqldump
--innodb-
- process composite keys correctly
- prevent only the first key indexing an AUTO_INCREMENT columns from
optimization
- use a simple pointer instead of the hash table to keep track of
AUTO_INCREMENT column with a simple pointer, as the server only allows
one such column per table anyway
http:// jenkins. percona. com/view/ PS%205. 1/job/percona- server- 5.1-param/ 464/