MySQL 5.5.28

Title:

MySQL 5.5.28

File Size:

31.1 MB

Requirements:

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

Language:

en-us

License:

Open Source

Date Added:

30 Sep 2012

Publisher:

MySQL AB

Homepage:

http://www.mysql.com

MD5 Checksum:

2BDBD13B4E8584CC732FAD0C9AAE1E99

# Functionality Added or Changed
* The internal interface of the Thread Pool plugin has changed. Old versions of the plugin will work with current versions of the server, but versions of the server older than 5.5.28 will not work with current versions of the plugin.
# Bugs Fixed
* InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS.
* InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned rows in an InnoDB table using a < or <= operator in a WHERE clause, the next row after the affected range could also be locked. This issue could cause a lock wait timeout for a row that was not expected to be locked. The issue occurred under various isolation levels, such as READ COMMITTED and REPEATABLE READ.
* Partitioning: For tables using PARTITION BY HASH or PARTITION BY KEY, when the partition pruning mechanism encountered a multi-range list or inequality using a column from the partitioning key, it continued with the next partitioning column and tried to use it for pruning, even if the previous column could not be used. This caused partitions which possibly matched one or more of the previous partitioning columns to be pruned away, leaving partitions that matched only the last column of the partitioning key.
- This issue was triggered when both of the following conditions were met:
> The columns making up the table's partitioning key were used in the same order as in the partitioning key definition by a SELECT statement's WHERE clause as in the column definitions;
> The WHERE condition used with the last column of the partitioning key was satisfied only by a single value, while the condition testing some previous column from the partitioning key was satisfied by a range of values.
An example of a statement creating a partitioned table and a query against this for which the issue described above occurred is shown here:
CREATE TABLE t1 (
c1 INT,
c2 INT,
PRIMARY KEY(c2, c1)
) PARTITION BY KEY() # Use primary key as partitioning key
PARTITIONS 2;
SELECT * FROM t1 WHERE c2 = 2 AND c1 <> 2;
This issue is resolved by ensuring that partition pruning skips any remaining partitioning key columns once a partition key column that cannot be used in pruning is encountered.
* Partitioning: The buffer for the row currently read from each partition used for sorted reads was allocated on open and freed only when the partitioning handler was closed or destroyed. For SELECT statements on tables with many partitions and large rows, this could cause the server to use excessive amounts of memory. This issue has been addressed by allocating buffers for reads from partitioned tables only when they are needed and freeing them immediately once they are no longer needed. As part of this fix, memory is now allocated for reading from rows only in partitions that have not been pruned.
* Replication: On 64-bit Windows platforms, values greater than 4G for the max_binlog_cache_size and max_binlog_stmt_cache_size system variables were truncated to 4G. This caused LOAD DATA INFILE to fail when trying to load a file larger than 4G in size, even when max_binlog_cache_size was set to a value greater than this.
* Replication: In master-master replication with --log-slave-updates enabled, setting a user variable and then performing inserts using this variable caused the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be updated.
* The RPM spec file now also runs the test suite on the new binaries, before packaging them.
* The libmysqlclient_r client library exported symbols from yaSSL that conflict with OpenSSL. If a program linked against that library and libcurl, it could crash with a segmentation fault.
* The argument for LIMIT must be an integer, but if the argument was given by a placeholder in a prepared statement, the server did not reject noninteger values such as '5'.
* The Thread Pool plugin did not respect the wait_timeout timeout for client sessions.
* CHECK TABLE and REPAIR TABLE could crash if a key definition differed in the .frm and .MYI files of a MyISAM table. Now the server produces an error.
* A query for a FEDERATED table could return incorrect results when the underlying table had a compound index on two columns and the query included an AND condition on the columns.
* mysqlhotcopy failed for databases containing views.
* The argument to the --ssl-key option was not verified to exist and be a valid key. The resulting connection used SSL, but the key was not used.
* Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause the optimizer to choose an incorrect index for processing the query, and return more rows than required.
* mysqlbinlog did not accept input on the standard input when the standard input was a pipe.