--local-infile=0 disables support for LOAD LOCAL INFILE in MySQL clients. However, this is currently enforced only on the server, which means that a "fake" server (that is, one that disregards the --local-infile setting) can read any files to which clients have access. It is assumed that this issue affects all MySQL client libraries and applications.

Target fix: 5.1+

Target fix: 5.1+

After mysql_change_user(), the character set variables should be just as after mysql_real_connect(). However, the server sets them to the global defaults. A workaround would be to explicitly reinitialize character set information explicitly following mysql_change_user().

Already fixed in: 5.1.23

Target fix: 4.1+

Already fixed in: 5.0+

Target fix: 5.0+

Target fix: 5.0+

Target fix: 5.1+

Queries against tables partioned by key using multiple columns for both the primary key and the partitioning can return the wrong number of rows.

Already fixed in: 5.1

Already fixed in: 5.1.?

Already fixed in: 5.0+

Already fixed in: 5.0+

Target fix: 5.0+

Already fixed in: 5.0+

Under some circumstances, a UDF initialization function could be passed incorrect argument lengths.

Already fixed in: 5.1.23

Already fixed in: 5.0+

Using ORDER BY as a clause within a SELECT on an archive table where the combined column length of the table is 510 bytes or larger triggers. the crash. One workaround is to use a subselect on the query.

Already fixed in: 5.1.23

Target fix: 5.1+

For a column that contains only empty strings, GROUP_CONCAT() returns "," rather than the correct result of "".

Already fixed in: 5.1.23

Already fixed in: 5.1.23

If a user changed a view with ALTER VIEW, the original DEFINER was retained, possibly allowing the new user to gain privileges. The fix will be to allow only the original view definer to alter the view.

Already fixed in: 5.1.23

Target fix: 5.1.24

On 64-bit systems, specifying a join_buffer size greater than 4GB would cause the value to wrap on the 4GB boundary. For example, a join_buffer of 5GB would actually only reserve 1GB. On 64-bit systems this restriction will be lifted. On 32-bit systems, the join_buffer size will be limited to 4GB.

Already fixed in: 5.1.23

Already fixed in: 5.1.23

Already fixed in: 5.1.23

A fix for this issue has been committed and is expected to appear in MySQL 5.1.23.

Already fixed in: 5.1.23

CHAR(str USING ucs2) for strings with an odd number of bytes did not add a leading 0x00 byte. Workaround: Provide an even-length string.

Already fixed in: 5.1.23

For CHAR(str USING charset) and CONVERT(str USING charset), no check was made that the string contained valid input for the character set (for example, CHAR(0xFF USING utf8) is invalid). An error should occur if the input is not well-formed.

Already fixed in: 5.1.23

For a character set introducer followed by a hex string, no check was made that the string contained valid input for the character set (for example, _utf8 0xFF is invalid). An error should occur if the input is not well-formed.

Already fixed in: 5.1.23

A fix for this issue has been committed and is expected to appear in MySQL 5.1.23.

Already fixed in: 5.1.23

Already fixed in: 5.1.23

Interpeted NDB API programs of sufficient size and complexity can in some cases cause data nodes to shut down due to buffer overruns. Note: This issue has already been fixed in MySQL Cluster Carrier Grade Edition (MySQL 5.1.22-ndb-6.3.4).

Already fixed in: 5.1.23

If an API or management node restarts or a network failure occurs, there is a short interval before data nodes can detect this, which results in a lingering connection.

Already fixed in: 5.1+

Target fix: 5.1

A Cluster backup fails to stop on its own if the disk on the data node runs out of space. Workaround: Monitor data node disk usage during Cluster backups. Note: A fix for this issue has been committed and is expected to appear in the next 5.1 release.

Target fix: 5.1.23

Creating a Disk Data log file or data file larger than 4 GB on a host running a 32-bit operating system leads to filesystem corruption on the host. Since this is a limitation of 32-bit operating systems, the workaround is not to create Disk Data files which are greater than 4 GB in size on such platforms. In the future, we plan to disallow statements creating Disk Data files whose size is greater than 4 GB on 32-bit hosts.

Target fix: 5.1

If the master mysqld node disconnects and reconnects to the cluster (for example, if the network connection is broken then re-established), a LOST_EVENTS entry is added to the binlog. However, when the master mysqld node crashes or has a normal restart it does not create the LOST_EVENTS entry. (This has already been fixed in MySQL Cluster Carrier Grade Edition releases 5.1.22-ndb-6.2.8 and 5.1.22-ndb-6.3.6.)

Already fixed in: 5.1.23

Under certain conditions, the slave may stop processing relay logs, which results in the logs never being cleared and the slave eventually running out of disk space. (Note: This issue has already been fixed in MySQL Cluster Carrier Grade versions 5.1.15-ndb-6.1.23 and 5.1.22-ndb-6.2.9.)

Already fixed in: 5.1.23

Client programs are not respecting the TCP/IP port number specified via the --with-tcp-port configure option. Workaround: Specify --port=port_num explicitly when invoking clients.

Already fixed in: 5.1.23

(Apparent) workaround: ELF executables need to be linked using the -export-dynamic option to ld(1) for symbols defined in the executable to become visible to dlsym().

Already fixed in: 5.1.23

Target fix: 5.0+

Already fixed in: 5.0+

RENAME DATABASE was intended only for updating names of pre-5.1 databases to the new 5.1 identifier encoding. It is being removed and replaced with ALTER TABLE db_name UPGRADE DATA DIRECTORY NAME.

Already fixed in: 5.1.23

RENAME DATABASE was intended only for updating names of pre-5.1 databases to the new 5.1 identifier encoding. It's being removed and replaced with ALTER TABLE db_name UPGRADE DATA DIRECTORY NAME.

Already fixed in: 5.1.23

Target fix: 5.1+

Target fix: 5.1+

The SQL_MODE setting is ignored when a client issues INSERT DELAYED. A patch for this bug has been approved for MySQL 5.0, and is expected to be committed to 5.1 in the near future.

Already fixed in: 5.1.23

Already fixed in: 5.1.23

Target fix: 5.1+

Already fixed in: 5.1.23

Issuing an ALTER SERVER statement to modify an existing SERVER specification as used by the Federated storage engine causes the server to crash.

Already fixed in: 5.1

Already fixed in: 5.0+

Target fix: 5.0+

This issue affects 32-bit platforms only. A fix has been committed that will prevent this buffer from being set too high on a 32-bit operating system. The fix will appear in 5.1.23.

Already fixed in: 5.1.23

For a spatial column with a regular (non-SPATIAL) index, queries failed if the optimizer tried to use the index. Workaround: Use IGNORE INDEX or remove the index (queries may be slow but will work).

Already fixed in: 5.1.23

Already fixed in: 5.1+

Using REGEX with ucs2 strings could cause a server crash. Workaround: Use an 8-bit character set if possible.

Already fixed in: 5.1.23

The implementation of ROUND() for DECIMAL/NUMERIC arguments could produce results where scale > precision, or where scale larger than the maximum allowable scale. One symptom is a crash when ORDER BY refers to an expression with ROUND().

Target fix: 5.0+

When invoked with constant arguments, STR_TO_DATE() could use a cached value for the format string and return incorrect results.

Already fixed in: 5.1.23

The Aborted_clients value could be incremented twice when a client exits without calling mysql_close(), resulting in an artificially high value.

Already fixed in: 5.1.23

Indexed and non-indexed searches for '0000-00-00' return different results after inserting '0000-00-00' and then setting the SQL mode to TRADITIONAL.

Already fixed in: 5.1.23

INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION was incorrect for views that are defined to select from other INFORMATION_SCHEMA tables.

Already fixed in: 5.1.23

Target fix: 5.1.24

During the Security Settings phase, a Connection Error can occur because the installer tries to proceed before the MySQL Server being installed is fully started. Workaround: wait a few moments, then click Retry in the error dialog.

Already fixed in: 5.1

The effect of this bug is that remote access cannot be enabled automatically for MySQL running on a Windows Vista host. This is an installer issue. The workaround is to add an exception for port 3306 to the Windows Wista firewall manually.

Already fixed in: 5.1+

Target fix: 5.0+

Already fixed in: 5.1+

Long statements written to the general query log might be truncated. One effect is that statements cannot be copied-and-pasted to re-execute them. There is currently no workaround.

Already fixed in: 5.1.23

Using a MEMORY table where the primary key is a compound key using two or more colums and btree indexing results in some rows not being deleted when the statement specifies only a single column from the primary key index.

Already fixed in: 5.1.23

A deadlock can be created if use LOCK TABLES simultaneously on a MERGE and related MYISAM table and then run FLUSH TABLE, but only if specify the MERGE table before the corresponding MYISAM table in the LOCK TABLES statement. Specifying the MYISAM table before the MERGE table does not cause the same problem.

Already fixed in: 5.1.23

Using a MERGE table, issuing a REPAIR TABLE on one connection while a LOCK TABLES statement is in place and an INSERT statement on the same table is waiting on another connection causes signficant CPU/memory usage.

Already fixed in: 5.1.23

Already fixed in: 5.1.23

See description for Bug#26379.

Already fixed in: 5.1.23

A combination of factors is involved in this issue: (1) the table must be a MERGE table; (2) perform the statements LOCK TABLE, REPAIR TABLE, and FLUSH TABLE on the merge and base tables; (3) perform INSERTs from multiple threads into the merge table. A fix for this bug has been prepared and is expected to appear in 5.1.23.

Already fixed in: 5.1.23

Setting certain values on a table using a spatial index could cause the server to crash. The cause is the calculation of certain values which exceed the expected levels when converted to the format used by the spatial indexing, leading to the incorrect key being written to the database and subsequent index updates failing. There is no known work around.

Already fixed in: 5.1.23

Already fixed in: 5.0+

Target fix: 5.1+

On 64-bit systems, specifying a myisam_sort_buffer size greater than 4GB would cause the value to wrap on the 4GB boundary. For example, a join_buffer of 5GB would actually only reserve 1GB. On 64-bit systems this restriction will be lifted. On 32-bit systems, the myisam_sort_buffer size will be limited to 4GB.

Already fixed in: 5.1.23

Inserting more than 2^32 (42924967295) rows into a single MYISAM table on windows, the row count is reset to 0. The data in the table is still accessible.

Already fixed in: 5.1.23

Target fix: 5.1+

Queries that contained constructs of the form "WHERE col NOT IN (col, ...)" (where the same column is named both places) caused a range optimizer crash.

Already fixed in: 5.1.23

Any user who is able to create/drop/alter tables may trivially crash the server daemon via the use of prepared statements. The only workaround to this possible DoS is to completely disallow prepared statements by setting the system variable max_prepared_stmt_count to 0.

Target fix: 5.1.25,6.0

A fix for this issue has been committed, and is expected to appear in MySQL 5.1.23.

Already fixed in: 5.1

A fix for this issue has been committed, and is expected to appear in MySQL 5.1.23.

Already fixed in: 5.1.23

The fix for this issue has been committed; the server now checks to insure that an attempt to refer in a PARTITION BY clause to a column belonging to a different table from that referred to in the partition definitions is not allowed.

Already fixed in: 5.1.23

Performing partition management statements such as ALTER TABLE ... REORGANIZE PARTITION while performing SELECT queries from the INFORMATION_SCHEMA.PARTITIONS table causes mysqld to crash. A fix for this issue has been committed, and is expected to appear in MySQL 5.1.23.

Already fixed in: 5.1.23

A patch has been committed for this issue and is expected to appear in 5.1.23 or 5.1.24.

Already fixed in: 5.1.23

The issue arises with a COUNT() query on an InnoDB table using PARTITION BY KEY(double_column). It does not occur with MyISAM tables. A fix has been committed and is expected to be part of 5.1.23.

Already fixed in: 5.1.23

Target fix: 5.1.24

Queries involving ordered index scans could cause a server crash when a partitioned table has an ENUM, SET, or DOUBLE column, even if this column is not used as a partitioning key. A fix has been committed for this issue and is expected to appear in MySQL 5.1.23.

Already fixed in: 5.1.23

If you create a table with PARTITION BY RANGE(unsigned_bigint_column) and PARTITION ... VALUES LESS THAN MAXVALUE, then try to insert the maximum possible value for BIGINT UNSIGNED (18446744073709551615), the INSERT statement apparently succeeds (in some cases with a warning, in others without one), but nothing is inserted into the table; the value is not truncated, and the statement does not produce an error.

Already fixed in: 5.1

When expanding a * in a USING or NATURAL join, the check for table access for both tables in the join was done using the grant information of the first table

Already fixed in: 5.1.23

Target fix: 5.1

The pthread_mutex_trylock() implementation is problematic on Windows and can cause a server crash when the query cache is invalidated. Workaround: Disable the query cache.

Already fixed in: 5.1.23

When an event has a short schedule (such as EVERY 1 SECONDS), it can sometimes happen that the event executes on the master but its effects are not propagated to the slave. The fix for this issue depends on the fix for Bug#12713, which is expected in 5.1.23.

Target fix: 5.1.24

A slave running MySQL 5.1.19 or newer cannot read logs generated by a master running MySQL 5.1.18 or earlier. This issue was apparently introduced by the fix for Bug#22583 in MySQL 5.1.18. Work is in progress on a lasting solution for this issue.

Target fix: 5.1

Target fix: 5.1.23

Row-based logging writes rows incorrectly on big-endian machines where the storage engine sets the low byte first on big-endian machines, while little-endian machines write the fields in correct order. (The only known storage engine that does this is NDB.) In effect, this means that row-based replication from or to a big-endian machine where the table uses NDB as storage engine fails if the other engine is either non-NDB or on a little-endian machine. A fix for this issue has been committed to 5.1.23.

Already fixed in: 5.1.23

The deletion is successful on the master but fails on the slave. A fix for this issue is in progress. See also Bug#31552.

Target fix: 5.1+

Already fixed in: 5.1.23

When using row based replication, the slave stops when attempting to delete non-existent rows from a slave table without a primary key. Known to occur with MyISAM, InnoDB and NDB tables. A fix for this issue has been committed, and is expected to appear in MySQL 5.1.23. See also Bug#31552 and Bug#32468.

Target fix: 5.1+

The sequence of events necessary to trigger this issue is unlikely to occur during normal manual operation, but may affect monitoring tools that execute SHOW SLAVE STATUS automatically. A fix has been done for this issue in 5.0 and is expected to be made to 5.1 in time for the 5.1-GA release.

Already fixed in: 5.0+

Workaround: Use row-based rather than statement-based replication of USER().

Already fixed in: 5.1.23

Target fix: 5.1+

An UPDATE statement setting a column of a non-transactional table to the value returned by a stored function that modifies is not logged if it fails, whereas any query that modifies a non-deterministic table should be logged even if there is an error in the execution. Otherwise, the master has a row in the non-transactional table that the slave does not have. A fix for this issue is pending; it is expected to appear in 5.1.23.

Already fixed in: 5.1.23

When a statement modifies an innodb table in autocommit mode, and the master crashes afterwards, but before writing the corresponding log event to disk, then the binlog may contain only the INSERT. In such a case, when the master restarts, InnoDB will roll back. The slave replicates the INSERT but not the ROLLBACK, and so the result is that on master the statement has been rolled back while on slave it is executed. This does not occur with AUTOCOMMIT turned off, since explicit BEGIN, COMMIT, and ROLLBACK statements are generated and logged. A fix is in progress, but it is not known at this whether it will be ready to appear in 5.1.23.

Target fix: 5.0+

Target fix: 5.1+

One thread in the MySQL replication code can read uninitialized memory from the stack of another thread. This appears to be strictly an internal issue; a fix has been prepared and is expected to be committed to the server code in time for MySQL 5.1.23 or 5.1.24.

Already fixed in: 5.0+

The workaround is to use parameters of INT types rather than BIT type.

Already fixed in: 5.1+

This is probably a memory corruption issue. (The relevant error code is ER_BAD_FIELD_ERROR.)

Already fixed in: 5.1.23

Already fixed in: 5.1.23

Already fixed in: 5.1.23

This occurs when using statement-based or mixed binlogging mode. When a user variable (such as "@something") is used inside an INSERT statement, the statement is replicated with invalid SQL syntax. A fix for this issue has been committed, and should appear in MySQL 5.1.23.

Target fix: 5.1.23

Target fix: 5.1+

Target fix: 5.0+

A fix for this issue has been committed and is expected to be included in MySQL 5.1.23.

Already fixed in: 5.1.23

This issue was encountered when upgrading the master and slave from MySQL 5.1.16 to 5.1.18. A patch is pending and is expected to be included in MySQL 5.1.23.

Already fixed in: 5.0+

Target fix: 5.0+

When AUTOCOMMIT=1, an error in a stored function called from a SELECT statement fails to roll back the statement. This can have consequences for row-based replication, such as the problem with scheduled events encountered in Bug#29020. A fix for this issue is expected in 5.1.23.

Target fix: 5.1.23

Already fixed in: 5.1.23

Target fix: 5.1.24

Using GROUP BY on an expression of the form timestamp_col DIV number caused a server crash due to incorrect calculation of number of decimals.

Already fixed in: 5.1.23

A fix has been written for this issue and is expected to appear in MySQL 5.1.23 or 5.1.24.

Already fixed in: 5.1.23