MySQL 5.1.37

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.37
Filename: mysql-essential-5.1.37-win32.msi
File size: 35.73MB (37,468,160 bytes)
Requirements: Windows 9x/2000/XP/2003/Vista
License: Open Source
Date added: August 3, 2009
Author: MySQL AB
www.mysql.com

Change Log:

* Important Change: Replication: RESET MASTER and RESET SLAVE now reset the values shown for Last_IO_Error, Last_IO_Errno, Last_SQL_Error, and Last_SQL_Errno in the output of SHOW SLAVE STATUS. (Bug#44270)

See also Bug#34654.

Bugs fixed:

* Partitioning: Security Fix: Accessing a table having user-defined partitioning when the server SQL mode included ONLY_FULL_GROUP_BY caused the MySQL server to crash. For example, the following sequence of statements crashed the server:

DROP TABLE IF EXISTS t1;

SET SESSION SQL_MODE='ONLY_FULL_GROUP_BY';

CREATE TABLE t1 (id INT, KEY(id))
PARTITION BY HASH(id) PARTITIONS 2;

(Bug#45807)

* Important Change: Replication: When using STATEMENT or MIXED binary logging format, a statement that changes both non-transactional and transactional tables must be written to the binary log whenever there are changes to non-transactional tables. This means that the statement goes into the binary log even when the changes to the transactional tables fail. In particular, in the event of a failure such statement is annotated with the error number and wrapped inside a pair of BEGIN and ROLLBACK statements.

On the slave, while applying the statement, it is expected that the same failure and the rollback prevent the transactional changes from persisting. However, statements that fail due to concurrency issues such as deadlocks and timeouts are logged in the same way, causing the slave to stop since the statements are applied sequentially by the SQL thread.

To address this issue, we ignore concurrency failures on the slave. Specifically, the following failures are now ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK, and ER_XA_RBDEADLOCK. (Bug#44581)

* Partitioning: Truncating a partitioned MyISAM table did not reset the AUTO_INCREMENT value. (Bug#35111)

* Replication: The SHOW SLAVE STATUS connection thread competed with the slave SQL thread for use of the error message buffer. As a result, the connection thread sometimes received incomplete messages. This issue was uncovered with valgrind when message strings were passed without NULL terminators, causing the error Conditional jump or move depends on uninitialised value(s). (Bug#45511)

See also Bug#43076.

* Replication: Large transactions and statements could corrupt the binary log if the size of the cache (as set by max_binlog_cache_size) was not large enough to store the changes.

Now, for transactions that do not fit into the cache, the statement is not logged, and the statement generates an error instead.

For non-transactional changes that do not fit into the cache, the statement is also not logged — an incident event is logged after committing or rolling back any pending transaction, and the statement then raises an error.
Note

If a failure occurs before the incident event is written the binary log, the slave does not stop, and the master does not report any errors.

(Bug#43929)

See also Bug#37148.

* Replication: The --database option for mysqlbinlog was ignored when using the row-based logging format. (Bug#42941)

* Replication: Shutting down the server while executing FLUSH LOGS, CHANGE MASTER TO, or STOP SLAVE could sometimes cause mysqld to crash. (Bug#38240)

* Replication: When reading a binary log that was in use by a master or that had not been properly closed (possibly due to a crash), the following message was printed: Warning: this binlog was not closed properly. Most probably mysqld crashed writing it. This message did not take into account the possibility that the file was merely in use by the master, which caused some users concern who were not aware that this could happen.

To make this clear, the original message has been replaced with Warning: this binlog is either is use or was not closed properly. (Bug#34687)

* The server crashed if evaluation of GROUP_CONCAT(... ORDER BY) required allocation of a sort buffer but allocation failed. (Bug#46080)

* When creating tables using the IBMDB2I storage engine with the ibmdb2i_create_index_option option set to 1, creating an IBMDB2I table with a primary key should produce an additional index that uses EBCDIC hexadecimal sorting, but this index was not created. (Bug#45983)

* With InnoDB tables, MySQL used a less-selective secondary index to avoid a filesort even if a prefix of the primary key was much more selective.

The fix for this problem might cause other queries to run more slowly. (Bug#45828)

* The server crashed for attempts to use REPLACE or INSERT ... ON DUPLICATE KEY UPDATE with a view defined using a join. (Bug#45806)

* Some collations were causing IBMDB2I to report inaccurate key range estimations to the optimizer for LIKE clauses that select substrings. This can be seen by running EXPLAIN. This problem primarily affects multi-byte and unicode character sets. (Bug#45803)

* Invalid memory reads and writes were generated when altering merge and base tables. This could lead to a crash or Valgrind errors:

==28038== Invalid write of size 1
at: memset (mc_replace_strmem.c:479)
by: myrg_attach_children (myrg_open.c:433)
by: ha_myisammrg::attach_children() (ha_myisammrg.cc:546)
by: ha_myisammrg::extra(ha_extra_function) (ha_myisammrg.cc:944)
by: attach_merge_children(TABLE_LIST*) (sql_base.cc:4147)
by: open_tables(THD*, TABLE_LIST**, unsigned*, unsigned) (sql_base.cc:4709)
by: open_and_lock_tables_derived(THD*, TABLE_LIST*, bool) (sql_base.cc:4977)
by: open_n_lock_single_table (mysql_priv.h:1550)
by: mysql_alter_table(sql_table.cc:6428)
by: mysql_execute_command(THD*) (sql_parse.cc:2860)
by: mysql_parse(THD*, char const*, unsigned, char const**) (sql_parse.cc:5933)
by: dispatch_command (sql_parse.cc:1213)

(Bug#45796)

* Inserting data into a table using the macce character set with the IBMDB2I storage engine would fail. (Bug#45793)

* There was a race condition when changing innodb_commit_concurrency at runtime to the value DEFAULT. (Bug#45749)

See also Bug#42101.

* Performing an empty XA transaction caused the server to crash for the next XA transaction. (Bug#45548)

* For replication of a stored procedure that uses the gbk character set, the result on the master and slave differed. (Bug#45485)

* SHOW CREATE TRIGGER requires the TRIGGER privilege but was not checking privileges. (Bug#45412)

* An assertion failure could occur if InnoDB tried to unlock a record when the clustered index record was unknown. (Bug#45357)

* Bug#19027 caused --enable-plugin_name (for example, --enable-innodb) not to work. (Bug#45336)

* If autocommit was enabled, InnoDB did not roll back DELETE or UPDATE statements if the statement was killed. (Bug#45309)

* Use of DECIMAL constants with more than 65 digits in CREATE TABLE ... SELECT statements led to spurious errors or assertion failures. (Bug#45262)

* The mysql client could misinterpret some character sequences as commands under some circumstances. (Bug#45236)

* Use of CONVERT() with an empty SET value could cause an assertion failure.
(Bug#45168)

* InnoDB recovery could hang due to redo logging of doublewrite buffer pages. (Bug#45097)

* when reading binary data, the concatenation function for geometry data collections did not rigorously check for available data, leading to invalid reads and server crashes. (Bug#44684)

* If an error occurred during the creation of a table (for example, the table already existed) having an AUTO_INCREMENT column and a BEFORE trigger that used the INSERT ... SELECT construct, an internal flag was not reset properly. This led to a crash the next time that the table was opened again. (Bug#44653)

* For queries with a sufficient number of subqueries in the FROM clause of this form:

SELECT * FROM (SELECT 1) AS t1,
(SELECT 2) AS t2,
(SELECT 3) AS t3, ...

The query failed with a Too high level of nesting for select error, as those the query had this form:

SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM ...

(Bug#44156)

* configure.in contained references to literal instances of nm and libc, rather than to variables parameterized for the proper values on the current platform. (Bug#42721)

* configure.in did not properly check for the pthread_setschedprio() function. (Bug#42599)

* A workaround for a Sun Studio bug was instituted. (Bug#41710)

* Valgrind warnings that occurred for SHOW TABLE STATUS with InnoDB tables were silenced. (Bug#38479)

* In the mysql client, if the server connection was lost during repeated status commands, the client would fail to detect this and command output would be inconsistent. (Bug#37274)

* When invoked to start multiple server instances, mysqld_multi sometimes would fail to start them all due to not changing location into the base directory for each instance. (Bug#36654)

* Renaming a column that appeared in a foreign key definition did not update the foreign key definition with the new column name. (Bug#21704)