520e4c1799
Bugs Fixed * Security Fix: Bug 59533 was fixed. * Performance: Partitioning: InnoDB Storage Engine: The statistics used by the optimizer for queries against partitioned InnoDB tables were based only on the first partition of each such table, leading to use of the wrong execution plan. * References: This bug was introduced by Bug 11756867. * Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE statement for InnoDB tables, especially on systems with a large buffer pool. The fix speeds up the processing for freeing entries in the adaptive hash index. * InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables within a short time could cause the purge operation that flushes data from the buffer pool to stall. If this issue occurs, restart the server to work around it. This issue is only likely to occur on 32-bit platforms. * InnoDB Storage Engine: If the server crashed during a TRUNCATE TABLE or CREATE INDEX statement for an InnoDB table, or a DROP DATABASE statement for a database containing InnoDB tables, an index could be corrupted, causing an error message when accessing the table after restart: InnoDB: Error: trying to load index index_name for table table_name InnoDB: but the index tree has been freed! In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in InnoDB storage engine. * InnoDB Storage Engine: When data was removed from an InnoDB table, newly inserted data might not reuse the freed disk blocks, leading to an unexpected size increase for the system tablespace or .ibd file (depending on the setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file in some cases but not others. The freed disk blocks would eventually be reused as additional data was inserted. More... |
||
---|---|---|
.. | ||
files | ||
buildlink3.mk | ||
DEINSTALL | ||
DESCR | ||
Makefile | ||
MESSAGE | ||
PLIST |