MySQL 5.1.53

MySQL Community Edition is a freely downloadable version of the world's most popular open source database that is supported by an active community of open source developers and enthusiasts.

MySQL delivers enterprise features, including:

* Partitioning to improve performance and management of very large database environments
* Row-based/Hybrid Replication for improved replication security
* Event Scheduler to create and schedule jobs that perform various database tasks
* XPath Support
* Dynamic General/Slow Query Log
* Performance/Load Testing Utility (mysqlslap)
* Improved! Full Text Search (faster, new dev templates)
* Improved! Archive engine (better compression, more features)
* Improved! User session and problem SQL identification
* Improved! MySQL embedded library (libmysqld)
* Additional INFORMATION_SCHEMA objects
* Faster data import operations (parallel file load)
* ACID Transactions to build reliable and secure business critical applications
* Stored Procedures to improve developer productivity
* Triggers to enforce complex business rules at the database level
* Views to ensure sensitive information is not compromised
* Information Schema to provide easy access to metadata
* Pluggable Storage Engine Architecture for maximum flexibility
* Archive Storage Engine for historical and audit data

Title: MySQL 5.1.53
Filename: mysql-essential-5.1.53-win32.msi
File size: 38.87MB (40,753,664 bytes)
Requirements: Windows 9x / 2000 / XP / 2003 / Vista / Windows7
Languages: en-US
License: Open Source
Date added: November 19, 2010
Author: MySQL AB
www.mysql.com

Change Log:

# Bugs fixed:
- Replication: SET PASSWORD caused row-based replication to fail between a MySQL 5.1 master and a MySQL 5.5 slave.
* This fix makes it possible to replicate SET PASSWORD correctly, using row-based replication between a master running MySQL 5.1.53 or a later MySQL 5.1 release to a slave running MySQL 5.5.7 or a later MySQL 5.5 release.
- Replication: An ALTER TABLE statement against a MyISAM table that altered a column without setting its size caused the binary log to become corrupted, leading to replication failure.
- Replication: When STOP SLAVE is issued, the slave SQL thread rolls back the current transaction and stops immediately if the transaction updates only tables which use transactional storage engines are updated. Previously, this occurred even when the transaction contained CREATE TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements, or both, although these statements cannot be rolled back. Because temporary tables persist for the lifetime of a user session (in the case, the replication user), they remain until the slave is stopped or reset. When the transaction is restarted following a subsequent START SLAVE statement, the SQL thread aborts with an error that a temporary table to be created (or dropped) already exists (or does not exist, in the latter case).
* Following this fix, if an ongoing transaction contains CREATE TEMPORARY TABLE statements, DROP TEMPORARY TABLE statements, or both, the SQL thread now waits until the transaction ends, then stops.
- Replication: If there exist both a temporary table and a non-temporary table having the same, updates normally apply only to the temporary table, with the exception of a CREATE TABLE ... SELECT statement that creates a non-temporary table having the same name as an existing temporary table. When such a statement was replicated using the MIXED logging format, and the statement was unsafe for row-based logging, updates were misapplied to the temporary table.
- Replication: When a slave tried to execute a transaction larger than the slave's value for max_binlog_cache_size, it crashed. This was caused by an assertion that the server should roll back only the statement but not the entire transaction when the error ER_TRANS_CACHE_FULL occurred. However, the slave SQL thread always rolled back the entire transaction whenever any error occurred, regardless of the type of error.
- Replication: When making changes to relay log settings using CHANGE MASTER TO, the I/O cache was not cleared. This could result in replication failure when the slave attempted to read stale data from the cache and then stopped with an assertion.
- Replication: Trying to read from a binary log containing a log event of an invalid type caused the slave to crash.
- Replication: When replicating the mysql.tables_priv table, the Grantor column was not replicated, and was thus left empty on the slave.
- Handling of host name lettercase in GRANT statements was inconsistent.