branches/zip:
Merge 2605:2617 from branches/5.1: ------------------------------------------------------------------------ r2609 | sunny | 2008-08-24 01:19:05 +0300 (Sun, 24 Aug 2008) | 12 lines Changed paths: M /branches/5.1/handler/ha_innodb.cc M /branches/5.1/mysql-test/innodb-autoinc.result M /branches/5.1/mysql-test/innodb-autoinc.test branches/5.1: Fix for MySQL Bug#38839. Reset the statement level last value field in prebuilt. This field tracks the last value in an autoincrement interval. We use this value to check whether we need to update a table's AUTOINC counter, if the value written to a table is less than this value then we avoid updating the table's AUTOINC value in order to reduce mutex contention. If it's not reset (e.g., after a DELETE statement) then there is the possibility of missing updates to the table's AUTOINC counter resulting in a subsequent duplicate row error message under certain conditions (see the test case for details). Bug #38839 - auto increment does not work properly with InnoDB after update ------------------------------------------------------------------------ r2617 | vasil | 2008-09-09 15:46:17 +0300 (Tue, 09 Sep 2008) | 47 lines Changed paths: M /branches/5.1/mysql-test/innodb.result branches/5.1: Merge a change from MySQL (fix the failing innodb test): ------------------------------------------------------------ revno: 2646.12.1 committer: Mattias Jonsson <mattiasj@mysql.com> branch nick: wl4176_2-51-bugteam timestamp: Mon 2008-08-11 20:02:03 +0200 message: Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that partition is corrupt The main problem was that ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION took another code path (over mysql_alter_table instead of mysql_admin_table) which differs in two ways: 1) alter table opens the tables in a different way than admin tables do resulting in returning with error before it tried the command 2) alter table does not start to send any diagnostic rows to the client which the lower admin functions continue to use -> resulting in assertion crash The fix: Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION to use the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE t. Adding check in mysql_admin_table to setup the partition list for which partitions that should be used. Partitioned tables will still not work with REPAIR TABLE/PARTITION USE_FRM, since that requires moving partitions to tables, REPAIR TABLE t USE_FRM, and check that the data still fulfills the partitioning function and then move the table back to being a partition. NOTE: I have removed the following functions from the handler interface: analyze_partitions, check_partitions, optimize_partitions, repair_partitions Since they are not longer needed. THIS ALTERS THE STORAGE ENGINE API I have verified that OPTIMIZE TABLE actually rebuilds the table and calls ANALYZE. Approved by: Heikki
Showing
Please register or sign in to comment