The mysql_odbc_escape_string() C API function has been removed. It has multi-byte character escaping issues, doesn't honor the NO_BACKSLASH_ESCAPES SQL mode and is not needed anymore by Connector/ODBC as of 3.51.17. (Bug#29592)

See also Bug#41728.

The argument for the mysql-test-run.pl --do-test and --skip-test options is now interpreted as a Perl regular expression if there is a pattern metacharacter in the argument value. This allows more flexible specification of which tests to perform or skip.

Performance: InnoDB had a race condition for an adaptive hash rw-lock waiting for an X-lock. This fix may also provide significant speed improvements on systems experiencing problems with contention for the adaptive hash index. (Bug#29560)

Security Enhancement: It was possible to force an error message of excessive length which could lead to a buffer overflow. This has been made no longer possible as a security precaution. (Bug#32707)

Incompatible Change: The MySQL 5.0.50 patch for this bug was reverted because it changed the behavior of a General Availability MySQL release. (Bug#30234)

See also Bug#27525.

Incompatible Change: It was possible for option files to be read twice at program startup, if some of the standard option file locations turned out to be the same directory. Now duplicates are removed from the list of files to be read.

Also, users could not override system-wide settings using ~/.my.cnf because SYSCONFDIR/my.cnf was read last. The latter file now is read earlier so that ~/.my.cnf can override system-wide settings.

The fix for this problem had a side effect such that on Unix, MySQL programs looked for options in ~/my.cnf rather than the standard location of ~/.my.cnf. That problem was addressed as Bug#38180. (Bug#20748)

Replication: It was possible for the name of the relay log file to exceed the amount of memory reserved for it, possibly leading to a crash of the server. (Bug#31836)

See also Bug#28597.

Replication: Corruption of log events caused the server to crash on 64-bit Linux systems having 4 GB or more of memory. (Bug#31793)

Replication: One thread could read uninitialized memory from the stack of another thread. This issue was only known to occur in a mysqld process acting as both a master and a slave. (Bug#30752)

Replication: Due a previous change in how the default name and location of the binary log file were determined, replication failed following some upgrades. (Bug#28597, Bug#28603)

See also Bug#31836.

This regression was introduced by Bug#20166.

Replication: Stored procedures having BIT parameters were not replicated correctly. (Bug#26199)

Replication: Issuing SHOW SLAVE STATUS as mysqld was shutting down could cause a crash. (Bug#26000)

Replication: An UPDATE statement using a stored function that modified a nontransactional table was not logged if it failed. This caused the copy of the nontransactional table on the master have a row that the copy on the slave did not.

In addition, when an INSERT ... ON DUPLICATE KEY UPDATE statement encountered a duplicate key constraint, but the UPDATE did not actually change any data, the statement was not logged. As a result of this fix, such statements are now treated the same for logging purposes as other UPDATE statements, and so are written to the binary log. (Bug#23333)

See also Bug#12713.

Replication: A replication slave sometimes failed to reconnect because it was unable to run SHOW SLAVE HOSTS. It was not necessary to run this statement on slaves (since the master should track connection IDs), and the execution of this statement by slaves was removed. (Bug#21132)

See also Bug#13963, Bug#21869.

An ORDER BY query using IS NULL in the WHERE clause did not return correct results. (Bug#32815)

Use of the cp932 character set with CAST() in an ORDER BY clause could cause a server crash. (Bug#32726)

A subquery using an IS NULL check of a column defined as NOT NULL in a table used in the FROM clause of the outer query produced an invalid result. (Bug#32694)

Specifying a nonexistent column for an INSERT DELAYED statement caused a server crash rather than producing an error. (Bug#32676)

Use of CLIENT_MULTI_QUERIES caused libmysqld to crash. (Bug#32624)

The INTERVAL() function incorrectly handled NULL values in the value list. (Bug#32560)

Use of a NULL-returning GROUP BY expression in conjunction with WITH ROLLUP could cause a server crash. (Bug#32558)

See also Bug#31095.

A SELECT ... GROUP BY bit_column query failed with an assertion if the length of the BIT column used for the GROUP BY was not an integer multiple of 8. (Bug#32556)

Using SELECT INTO OUTFILE with 8-bit ENCLOSED BY characters led to corrupted data when the data was reloaded using LOAD DATA INFILE. This was because SELECT INTO OUTFILE failed to escape the 8-bit characters. (Bug#32533)

For FLUSH TABLES WITH READ LOCK, the server failed to properly detect write-locked tables when running with low-priority updates, resulting in a crash or deadlock. (Bug#32528)

Sending several KILL QUERY statements to target a connection running SELECT SLEEP() could freeze the server. (Bug#32436)

ssl-cipher values in option files were not being read by libmysqlclient. (Bug#32429)

Repeated execution of a query containing a CASE expression and numerous AND and OR relations could crash the server. The root cause of the issue was determined to be that the internal SEL_ARG structure was not properly initialized when created. (Bug#32403)

Referencing within a subquery an alias used in the SELECT list of the outer query was incorrectly permitted. (Bug#32400)

An ORDER BY query on a view created using a FEDERATED table as a base table caused the server to crash. (Bug#32374)

Comparison of a BIGINT NOT NULL column with a constant arithmetic expression that evaluated to NULL mistakenly caused the error Column '...' cannot be null (error 1048). (Bug#32335)

Assigning a 65,536-byte string to a TEXT column (which can hold a maximum of 65,535 bytes) resulted in truncation without a warning. Now a truncation warning is generated. (Bug#32282)

The LAST_DAY() function returns a DATE value, but internally the value did not have the time fields zeroed and calculations involving the value could return incorrect results. (Bug#32270)

MIN() and MAX() could return incorrect results when an index was present if a loose index scan was used. (Bug#32268)

Memory corruption could occur due to large index map in Range checked for each record status reported by EXPLAIN SELECT. The problem was based in an incorrectly calculated length of the buffer used to store a hexadecimal representation of an index map, which could result in buffer overrun and stack corruption under some circumstances. (Bug#32241)

Various test program cleanups were made: 1) mytest and libmysqltest were removed. 2) bug25714 displays an error message when invoked with incorrect arguments or the --help option. 3) mysql_client_test exits cleanly with a proper error status. (Bug#32221)

For comparisons of the form date_col OP datetime_const (where OP is =, <, >, <=, or >=), the comparison is done using DATETIME values, per the fix for Bug#27590. However that fix caused any index on date_col not to be used and compromised performance. Now the index is used again. (Bug#32198)

DATETIME arguments specified in numeric form were treated by DATE_ADD() as DATE values. (Bug#32180)

InnoDB does not support SPATIAL indexes, but could crash when asked to handle one. Now an error is returned. (Bug#32125)

With lower_case_table_names set, CREATE TABLE LIKE was treated differently by libmysqld than by the nonembedded server. (Bug#32063)

Within a subquery, UNION was handled differently than at the top level, which could result in incorrect results or a server crash. (Bug#32036, Bug#32051)

Changing the SQL mode to cause dates with “zero” parts to be considered invalid (such as '1000-00-00') could result in indexed and nonindexed searches returning different results for a column that contained such dates. (Bug#31928)

ucs2 does not work as a client character set, but attempts to use it as such were not rejected. Now character_set_client cannot be set to ucs2. This also affects statements such as SET NAMES and SET CHARACTER SET. (Bug#31615)

Killing a CREATE TABLE ... LIKE statement that was waiting for a name lock caused a server crash. When the statement was killed, the server attempted to release locks that were not held. (Bug#31479)

myisamchk --unpack could corrupt a table that when unpacked has static (fixed-length) row format. (Bug#31277)

Server variables could not be set to their current values on Linux platforms. (Bug#31177)

See also Bug#6958.

Data in BLOB or GEOMETRY columns could be cropped when performing a UNION query. (Bug#31158)

The server crashed in the parser when running out of memory. Memory handling in the parser has been improved to gracefully return an error when out-of-memory conditions occur in the parser. (Bug#31153)

MySQL declares a UNIQUE key as a PRIMARY key if it doesn't have NULL columns and is not a partial key, and the PRIMARY key must alway be the first key. However, in some cases, a nonfirst key could be reported as PRIMARY, leading to an assert failure by InnoDB. This is fixed by correcting the key sort order. (Bug#31137)

REGEXP operations could cause a server crash for character sets such as ucs2. Now the arguments are converted to utf8 if possible, to allow correct results to be produced if the resulting strings contain only 8-bit characters. (Bug#31081)

Many nested subqueries in a single query could led to excessive memory consumption and possibly a crash of the server. (Bug#31048)

The optimizer incorrectly optimized conditions out of the WHERE clause in some queries involving subqueries and indexed columns. (Bug#30788)

Improper calculation of CASE expression results could lead to value truncation. (Bug#30782)

A multiple-table UPDATE involving transactional and nontransactional tables caused an assertion failure. (Bug#30763)

mysql-test-run.pl could not run mysqld with root privileges. (Bug#30630)

The options available to the CHECK TABLE statement were also allowed in OPTIMIZE TABLE and ANALYZE TABLE statements, but caused corruption during their execution. These options were never supported for these statements, and an error is now raised if you try to apply these options to these statements. (Bug#30495)

When casting a string value to an integer, cases where the input string contained a decimal point and was long enough to overrun the unsigned long long type were not handled correctly. The position of the decimal point was not taken into account which resulted in miscalculated numbers and incorrect truncation to appropriate SQL data type limits. (Bug#30453)

For CREATE ... SELECT ... FROM, where the resulting table contained indexes, adding SQL_BUFFER_RESULT to the SELECT part caused index corruption in the table. (Bug#30384)

The optimizer made incorrect assumptions about the value of the is_member value for user-defined functions, sometimes resulting in incorrect ordering of UDF results. (Bug#30355)

Some valid euc-kr characters having the second byte in the ranges [0x41..0x5A] and [0x61..0x7A] were rejected. (Bug#30315)

Simultaneous ALTER TABLE statements for BLACKHOLE tables caused 100% CPU use due to locking problems. (Bug#30294)

Tables with a GEOMETRY column could be marked as corrupt if you added a non-SPATIAL index on a GEOMETRY column. (Bug#30284)

On some 64-bit systems, inserting the largest negative value into a BIGINT column resulted in incorrect data. (Bug#30069)

The mysql client program now ignores Unicode byte order mark (BOM) characters at the beginning of input files. Previously, it read them and sent them to the server, resulting in a syntax error.

Presence of a BOM does not cause mysql to change its default character set. To do that, invoke mysql with an option such as --default-character-set=utf8. (Bug#29323)

For transactional tables, an error during a multiple-table DELETE statement did not roll back the statement. (Bug#29136)

Denormalized double-precision numbers cannot be handled properly by old MIPS pocessors. For IRIX, this is now handled by enabling a mode to use a software workaround. (Bug#29085)

When doing a DELETE on a table that involved a JOIN with MyISAM or MERGE tables and the JOIN referred to the same table, the operation could fail reporting ERROR 1030 (HY000): Got error 134 from storage engine. This was because scans on the table contents would change because of rows that had already been deleted. (Bug#28837)

A race condition between killing a statement and the thread executing the statement could lead to a situation such that the binary log contained an event indicating that the statement was killed, whereas the statement actually executed to completion. (Bug#27571)

Some queries using the NAME_CONST() function failed to return either a result or an error to the client, causing it to hang. This was due to the fact that there was no check to insure that both arguments to this function were constant expressions. (Bug#27545, Bug#32559)

mysqld sometimes miscalculated the number of digits required when storing a floating-point number in a CHAR column. This caused the value to be truncated, or (when using a debug build) caused the server to crash. (Bug#26788)

See also Bug#12860.

If the expected precision of an arithmetic expression exceeded the maximum precision supported by MySQL, the precision of the result was reduced by an unpredictable or arbitrary amount, rather than to the maximum precision. In some cases, exceeding the maximum supported precision could also lead to a crash of the server. (Bug#24907)

Zero-padding of exponent values was not the same across platforms. (Bug#12860)

If an INSERT ... SELECT statement is executed, and no automatically generated value is successfully inserted, then mysql_insert_id() returns the ID of the last inserted row.

If no automatically generated value is successfully inserted, then mysql_insert_id() returns 0. (Bug#9481)