MySQL 5.5.15

Title:

MySQL 5.5.15

File Size:

27.8 MB

Requirements:

Windows 9x / 2000 / XP / Vista / Windows7 / Windows8

Language:

en-us

License:

Open Source

Date Added:

27 Jul 2011

Publisher:

MySQL AB

Homepage:

http://www.mysql.com

MD5 Checksum:

6D6B482D467BB3D26F935AF6EEE63F7E

# Bugs Fixed :
* InnoDB Storage Engine: A failed CREATE INDEX operation for an InnoDB table could result in some memory being allocated and not freed. This memory leak could affect tables created with the ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED settings.
* Partitioning: Auto-increment columns of partitioned tables were checked even when they were not being written to. In debug builds, this could lead to a crash of the server.
* Partitioning: The UNIX_TIMESTAMP() function was not treated as a monotonic function for purposes of partition pruning.
* Replication: If a LOAD DATA INFILE statement—replicated using statement-based replication—featured a SET clause, the name-value pairs were regenerated using a method (Item::print()) intended primarily for generating output for statements such as EXPLAIN EXTENDED, and which cannot be relied on to return valid SQL. This could in certain cases lead to a crash on the slave. To fix this problem, we now name each value in its original, user-supplied form, and use that to create LOAD DATA INFILE statements for statement-based replication.
* Previously, an inappropriate error message was produced if a multiple-table update for an InnoDB table with a clustered primary key would update a table through multiple aliases, and perform an update that may physically move the row in at least one of these aliases. Now the error message is: Primary key/partition key update is not allowed since the table is updated both as 'tbl_name1' and 'tbl_name2'
* ALTER TABLE {MODIFY|CHANGE} ... FIRST did nothing except rename columns if the old and new versions of the table had exactly the same structure with respect to column data types. As a result, the mapping of column name to column data was incorrect. The same thing happened for ALTER TABLE DROP COLUMN, ADD COLUMN statements intended to produce a new version of table with exactly the same structure as the old version.
* Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCK for statements requiring prelocking caused two problems:
- Execution of any data-changing statement that required prelocking (that is, involved a stored function or trigger) as part of transaction slowed down somewhat all subsequent statements in the transaction. Performance in a transaction that periodically involved such statements gradually degraded over time.
- Execution of any data-changing statement that required prelocking as part of transaction prevented a concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction rather than at the end of the particular statement.
* The fractional part of the “Queries per second” value in MySQL status output could be displayed incorrectly.
* LOAD DATA INFILE incorrectly parsed relative data file path names that ascended more than three levels in the file system and as a consequence was unable to find the file.
* For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption.
* In debug builds, Field_new_decimal::store_value() was subject to buffer overflows.
* A race condition between loading a stored routine using the name qualified by the database name and dropping that database resulted in a spurious error message: The table mysql.proc is missing, corrupt, or contains bad data