As of MySQL 5.4.2, the InnoDB Plugin is included in MySQL 5.4 releases. The version of the InnoDB Plugin in this release is 1.0.4 and is considered of Beta quality. It becomes the built-in version of InnoDB in MySQL Server, replacing the version previously included as the built-in InnoDB engine.

A number of performance and scalability enhancements were made to the previous built-in version of InnoDB in MySQL 5.4.0 and 5.4.1. InnoDB Plugin also provides improvements in these areas, and in addition offers new features and capabilities for flexibility and ease of use. Among these features are enhanced reliability, “Fast index creation,” table and index compression, file format management, new INFORMATION_SCHEMA tables, capacity tuning, multiple background I/O threads, and group commit.

For information about these features, see the InnoDB Plugin Manual at http://www.innodb.com/products/innodb_plugin/plugin-documentation. For general information about using InnoDB in MySQL, see Section 13.6, “The InnoDB Storage Engine”.

Due to inclusion of InnoDB Plugin, a number of InnoDB configuration changes were made, as described later in this section.

Incompatible Change: The inclusion of InnoDB Plugin as the built-in version of InnoDB in MySQL Server results in an incompatibility for upgrades from MySQL 5.1. InnoDB Plugin is available in MySQL 5.1 as of 5.1.38, but it is an optional storage engine that must be enabled explicitly using two server options:

[mysqld]
ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so

If you were using InnoDB Plugin in MySQL 5.1 by means of those options, you must remove them after an upgrade to 5.4 or the server will fail to start.

Incompatible Change: If you upgrade to MySQL 5.4.2 from MySQL 5.1, the server may fail to start due to InnoDB log file configuration changes. MySQL 5.4 increases the default value of innodb_log_files_in_group from 2 to 3. It also increases the default value of innodb_log_file_size from 5MB to 128MB. (MySQL 5.4.0 increased the minimum value of innodb_log_file_size from 1MB to 32MB, but this has been reverted to 1MB in 5.4.2.)

For an upgrade to MySQL 5.4.2, you should discard the old InnoDB log files and let MySQL 5.4.2 create new ones. It is necessary to shut down your current server cleanly so that no outstanding transaction information remains in the log. The procedure to use depends on the value of innodb_fast_shutdown used in your current server:

Incompatible Change: The following list indicates InnoDB configuration changes in MySQL 5.4.2, compared to previous versions of MySQL 5.4. For a description of cumulative changes in MySQL 5.4 compared to MySQL 5.1, see Section 1.5, “What Is New in MySQL 5.4”.

These system variables were added:

More information about the new system variables can be found in the InnoDB Plugin Manual at http://www.innodb.com/products/innodb_plugin/plugin-documentation.

These system variables have been made dynamic and can be modified at runtime:

These system variables were removed, along with the functionality that they represented:

The minimum value of these system variables was changed:

These minimum value changes in most cases revert changes made in MySQL 5.4.0.

The default value of this system variable was changed:

These status variables were renamed or removed:

Important Change: Replication: Previously, incident log events were represented as comments in the output from mysqlbinlog, making them effectively silent when playing back the binlog.

(An incident log event represents an incident that could cause the contents of the database to change without that event being recorded in the binary log.)

This meant that, if the SQL were applied to a server, it could potentially lead to the master and the slave having different data. To make it possible to handle incident log events without breaking applications that expect the previous behavior, the nonsense statement RELOAD DATABASE is added to the SQL output for that incident log event, which causes an error.

To use this functionality currently requires hand editing of the dump file and handling of each case on an individual basis by a database administrator before applying the output to a server. (Bug#44442)

Replication: With statement-based logging (SBL), repeatedly calling statements that are unsafe for SBL caused a warning message to be written to the error log for each statement, and there was no way to disable this behavior. Now the server logs messages about statements that are unsafe for statement-based logging only if the log_warnings variable is greater than 0. (Bug#46265)

The undocumented TRANSACTIONAL and PAGE_CHECKSUM keywords were removed from the grammar. (Bug#45829)

The minimum value for table_open_cache was increased from 64 to 400. (Bug#45475)

mysql_upgrade now displays a message indicating the connection parameters it uses when invoking mysqlcheck. (Bug#44638)

Previously, mysqldump would not dump the INFORMATION_SCHEMA database and ignored it if it was named on the command line. Now, mysqldump will dump INFORMATION_SCHEMA if it is named on the command line. Currently, this requires that the --skip-lock-tables (or --skip-opt) option be given. (Bug#33762)

Previously, SELECT ... INTO OUTFILE dumped column values without character set conversion, which could produce data files that cannot be imported without error if different columns used different character sets. A consequence of this is that mysqldump ignored the --default-character-set option if the --tab option was given (which causes SELECT ... INTO OUTFILE to be used to dump data.)

INTO OUTFILE now can be followed by a CHARACTER SET clause indicating the character set to which dumped values should be converted. Also, mysqldump adds a CHARACTER SET clause to the SELECT ... INTO OUTFILE statement used to dump data, so that --default-character-set is no longer ignored if --tab is given.

Other changes are that SELECT ... INTO OUTFILE enforces that ENCLOSED BY and ESCAPED BY arguments must be a single character, and SELECT ... INTO OUTFILE and LOAD DATA INFILE produce warnings if non-ASCII field or line separators are specified. (Bug#30946)

The maximum value for max_binlog_cache_size has been increased from 2³² – 1 to 2⁶⁴ – 1 (even on 32-bit platforms), which enables transactions 4GB and larger to be performed when binary logging is enabled. (Bug#10206)

Pluggable storage engines now can be built for Windows.

On Linux, the performance of MySQL Server can be improved by using a different malloc() implementation, developed by Google and called tcmalloc. The gain is noticeable with a higher number of simultaneous users. MySQL 5.4.1 was linked against this library, which improved performance but imposed some restrictions. As a result of these restrictions, MySQL 5.4.2 uses a different approach:

The MySQL euckr character set now can store extended codes [81...FE][41..5A,61..7A,81..FE], which makes euckr compatible with the Microsoft cp949 character set.

The optimizer_switch system variable is now available to control optimizations that can be switched on and off. See Section 7.2.19, “Using optimizer_switch to Control the Optimizer”.

Performance: 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)

Performance: InnoDB uses random numbers to generate dives into indexes for calculating index cardinality. However, under certain conditions, the algorithm did not generate random numbers, so ANALYZE TABLE did not update cardinality estimates properly. A new algorithm has been introduced with better randomization properties. (Bug#43660)

Performance: The table cache lock (LOCK_open) is now an adaptive mutex, which should improve performance in workloads where this lock is heavily contended. (Bug#43435)

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)

Security Fix: The strxnmov() library function could write a null byte after the end of the destination buffer. (Bug#44834)

Security Fix: Four potential format string vulnerabilities were fixed (discovered by the Veracode code analysis). (Bug#44166)

Incompatible Change: The server can load plugins under the control of startup options. For example, many storage engines can be built in pluggable form and loaded when the server starts. In the following descriptions, plugin_name stands for a plugin name such as innodb.

Previously, plugin options were handled like other boolean options (see Section 4.2.3.2, “Program Option Modifiers”). That is, any of these options enabled the plugin:

--plugin_name
--plugin_name=1
--enable-plugin_name

And these options disabled the plugin:

--plugin_name=0
--disable-plugin_name
--skip-plugin_name

However, use of a boolean option for plugin loading did not provide control over what to do if the plugin failed to start properly: Should the server exit, or start with the plugin disabled? The actual behavior has been that the server starts with the plugin disabled, which can be problematic. For example, if InnoDB fails to start, existing InnoDB tables become inaccessible, and attempts to create new InnoDB tables result in tables that use the default storage engine unless the NO_ENGINE_SUBSTITUTION SQL mode has been enabled to cause an error to occur instead.

Now, there is a change in the options used to control plugin loading, such that they have a tristate format:

The values OFF, ON, and FORCE are not case sensitive.

Suppose that CSV and InnoDB have been built as pluggable storage engines and that you want the server to load them at startup, subject to these conditions: The server is allowed to run if CSV initialization fails, but must require that InnoDB initialization succeed. To accomplish that, use these lines in an option file:

[mysqld]
csv=ON
innodb=FORCE

This change is incompatible with the previous implementation if you used options of the form --plugin_name=0 or --plugin_name=1, which should be changed to --plugin_name=OFF or --plugin_name=ON, respectively.

--enable-plugin_name is still supported and is the same as --plugin_name=ON. --disable-plugin_name and --skip-plugin_name are still supported and are the same as --plugin_name=OFF. (Bug#19027)

See also Bug#45336.

Important Change: Replication: BEGIN, COMMIT, and ROLLBACK statements are no longer affected by --replicate-do-db or --replicate-ignore-db rules. (Bug#43263)

Important Change: Replication: The transactional behavior of STOP SLAVE has changed. Formerly, it took effect immediately, even inside a transaction; now, it waits until the current replication event group (if any) has finished executing, or until the user issues a KILL QUERY or KILL CONNECTION statement.

This was done in order to solve the problem encountered when replication was stopped while a nontransactional slave was replicating a transaction on the master. (It was impossible to roll back a mixed-engines transaction when one of the engines was nontransactional, which meant that the slave could not safely re-apply any transaction that had been interrupted by STOP SLAVE.) (Bug#319, Bug#38205)

See also Bug#43217.

Partitioning: Attempting to create a table using an invalid or inconsistent subpartition definition caused the server to crash. An example of such a statement is shown here:

CREATE TABLE t2 (s1 INT, s2 INT)
PARTITION BY LIST (s1) SUBPARTITION BY HASH (s2) SUBPARTITIONS 1
(
    PARTITION p1 VALUES IN (1),
    PARTITION p2 VALUES IN (2) (SUBPARTITION p3)  
);

(Bug#46354)

Partitioning: A failed RENAME TABLE operation on a table with user-defined partitioning left the table in an unusable state, due to only some of the table files having been renamed. (Bug#30102)

Replication: When a statement that changes a nontransactional table failed, the transactional cache was flushed, causing a mismatch between the execution and logging histories. Now we avoid flushing the transactional cache unless a COMMIT or ROLLBACK is issued. (Bug#46129)

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

Replication: The internal function purge_relay_logs() did not propagate an error occurring in another internal function count_relay_log_space(). (Bug#44115)

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 nontransactional 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.

(Bug#43929)

See also Bug#37148.

Replication: When using the MIXED logging format, after creating a temporary table and performing an update that switched the logging format to ROW, the format switch persisted following the update. This prevented any subsequent DDL statements on temporary tables from being written to the binary log until the temporary table was dropped. (Bug#43046)

See also Bug#40013.

This regression was introduced by Bug#20499.

Replication: Statements using LIMIT generated spurious Statement is not safe to log in statement format warnings in the error log, causing the log to grow rapidly in size. (Bug#42851)

See also Bug#46265, Bug#42415.

This regression was introduced by Bug#34768.

Replication: When using row-based logging, the length of an event for which the field metadata exceeded 255 bytes in size was incorrectly calculated. This could lead to corruption of the binary log, or cause the server to hang. (Bug#42749)

See also Bug#44548, Bug#44672, Bug#44752.

Replication: The warning Statement is not safe to log in statement format, issued in situations when it cannot be determined that a statement or other database event can be written reliably to the binary log using the statement-based format, has been changed to Statement may not be safe to log in statement format. (Bug#42415)

Replication: The Query_log_event used by replication to transfer a query to the slave has been refactored. Query_log_event also stores and sends the error code resulting from the execution since it, in some cases, is necessary to execute the statement on the slave as well, which should result in the same error code. The Query_log_event constructor previously worked out for itself the error code using a complex routine, the result of which was often set aside within the constructor itself. This was also involved with at least 2 known bugs relating to invalid errors, and taken as a clear sign that the constructor was not well-designed and needed to be re-written. (Bug#41948)

See also Bug#37145.

Replication: When replicating many temporary tables and inserts into those tables, executing STOP SLAVE followed by START SLAVE could cause the server to crash. This appeared to be caused by temporary tables preserving outdated thread references after the restart. (Bug#41725)

Replication: If the --log-bin-trust-function-creators option is not enabled, CREATE FUNCTION requires one of the modifiers DETERMINISTIC, NO SQL, or READS SQL DATA. When using statement-based mode, the execution of a stored function should follow the same rules; however, only functions defined with DETERMINISTIC could actually be executed. In addition, the wrong error was generated (ER_BINLOG_ROW_RBR_TO_SBR instead of ER_BINLOG_UNSAFE_ROUTINE).

Now execution of stored functions is compatible with creation in this regard; when a stored function without one of the modifiers above is executed in STATEMENT mode, the correct error is raised, and functions defined using NO SQL, READS SQL DATA, or both (that is, without using DETERMINISTIC) can be excuted. (Bug#41166)

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)

open_binary_frm() performed a version test incorrectly, resulting in Valgrind errors. (Bug#46652)

Concurrent INSERT INTO ... SELECT statements for an InnoDB table could cause an AUTO_INCREMENT assertion failure. (Bug#46650)

Incorrect index optimization could lead to incorrect results or server crashes. (Bug#46454)

The server printed warnings at startup about adjusting the value of the max_join_size system variable. (These were harmless, but might be seen by users as significant.) (Bug#46385)

mysql did not handle backspace properly for multi-byte characters. This has been fixed now if mysql is linked with the readline library. It is not fixed if mysql is linked with libedit, which does not contain the necessary support for multi-byte character sets. (Bug#46310)

For InnoDB tables, an unnecessary table rebuild for ALTER TABLE could sometimes occur if ROW_FORMAT was specified. (Bug#46160)

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

An optimization that moved an item from a subquery to an outer query could cause a server crash. (Bug#46051)

Several Valgrind warnings were corrected. (Bug#46003, Bug#46034, Bug#46042)

CREATE TABLE ... SELECT could cause a server crash if no default database was selected. (Bug#45998)

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)

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)

The MySQL Server crashed when performing a REPLACE into a MERGE table if there was a duplicate. (Bug#45800)

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

For problems reading SSL files during SSL initialization, the server wrote error messages to stderr rather than to the error log. (Bug#45770)

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)

The vendor name change from MySQL AB to Sun Microsystems, Inc. in RPM packages was not handled gracefully when upgrading MySQL using an RPM package. (Bug#45534)

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)

Linker failures with libmysqld on VC++ 2008 were fixed. (Bug#45326)

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

Compiler warnings on Mac OS X were fixed. (Bug#45286)

The optimizer mishandled “impossible range” conditions and returned empty results due to an uninitialized variable. (Bug#45266)

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)

Running a SELECT query over an IBMDB2I table using the cp1250 character set would produce an error

ibmdb2i error 2027: Error converting single-byte sort sequence to UCS-2 

(Bug#45197)

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

Use of ROUND() on a LONGTEXT or LONGBLOB column of a derived table could cause a server crash. (Bug#45152)

A problem of compiler register misallocation on 32-bit Linux was corrected. (Bug#45131)

DROP USER could fail to drop all privileges for an account if the PAD_CHAR_TO_FULL_LENGTH SQL mode was enabled. (Bug#45100)

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

Invalid memory reads could occur using the compressed client/server protocol. (Bug#45031)

Invalid input could cause invalid memory reads by the parser. (Bug#45010)

GROUP BY on a constant (single-row) InnoDB table joined to other tables caused a server crash. (Bug#44886)

ALTER TABLE on a view crashed the server. (Bug#44860)

When using partitioning with the IBMDB2I storage engine, the engine could report that a valid character set was not supported. (Bug#44856)

Running queries on tables with the IBMDB2I storage engine using the utf8 character would fail when using the 64-bit version of MySQL. (Bug#44811)

Index Merge followed by a filesort could result in a server crash if sort_buffer_size was not large enough for all sort keys. (Bug#44810)

See also Bug#40974.

UNCOMPRESSED_LENGTH() returned a garbage result when passed a string shorter than 5 bytes. Now UNCOMPRESSED_LENGTH() returns NULL and generates a warning. (Bug#44796)

Several Valgrind warnings were silenced. (Bug#44774, Bug#44792)

Selecting RAND(N) function where N is a column of a constant table (table with a single row) failed with a SIGFPE signal. (Bug#44768)

The PASSWORD() and OLD_PASSWORD() functions could read memory outside of an internal buffer when used with BLOB arguments. (Bug#44767)

Conversion of a string to a different character set could use the same buffer for input and output, leading to incorrect results or warnings. (Bug#44743, Bug#44766)

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)

Some deprecation warning messages indicated feature removal in MySQL 5.2 rather than MySQL 6.0. (Bug#44676)

Code that optimized a read-only XA transaction failed to reset the XID once the transaction was no longer active. (Bug#44672)

During incorporation of a Google patch to SHOW ENGINE INNODB STATUS in MySQL 5.4.0, the TRANSACTIONS section of the output was inadvertently omitted. This section has been restored. (Bug#44671)

A Valgrind warning related to transaction processing was silenced. (Bug#44664)

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 the table was opened again. (Bug#44653)

Some files in an AIX tar file distribution unpacked with incorrect permissions. (Bug#44647)

When creating tables using the IBMDB2I storage engine, the RCDFMT (record format) that would be applied to the corresponding files within the IBM i would be set according to the table name. During whole table operations, the name could get modified to a value inconsistent with the table name. In addition, the record format would be inconsistent compared to the file content. The IBMDB2I storage engine now adds an explicit RCDFMT clause to the CREATE TABLE statement passed down to the DB2 storage engine layer. (Bug#44610)

Using mysql_stmt_execute() to call a stored procedure could cause a server crash. (Bug#44495)

innochecksum could incorrectly determine the input file name from the arguments. (Bug#44484)

The my-innodb-heavy-4G.cnf sample option file contained a setting for the no longer existing innodb_file_io_threads system variable. This has been replaced with settings for the innodb_write_io_threads and innodb_read_io_threads system variables with which innodb_file_io_threads has been replaced. (Bug#44470)

Creating a new instance after previously removing an instance would fail to complete the installation properly because the security settings could not be applied correctly. (Bug#44428)

Incorrect time was reported at the end of mysqldump output. (Bug#44424)

mysqlslap ignored the --csv option if it was given without an argument. (Bug#44412)

Caching of GROUP BY expressions could lead to mismatches between compile-time and runtime calculations and cause a server crash. (Bug#44399)

A deprecation warning message tested for an incorrect version number and caused an assertion failure. (Bug#44394)

Lettercase conversion in multibyte cp932 or sjis character sequences could produce incorrect results. (Bug#44352)

Assertion failure could occur for duplicate-key errors in INSERT INTO ... SELECT statements. (Bug#44306)

Incomplete cleanup of JOIN_TAB::select during the filesort of rows for a GROUP BY clause inside a subquery caused a server crash. (Bug#44290)

Trying to use an unsupported character set on an IBMDB2I table would produce DB2 error 2501 or 2511. The error has been updated to produce Error 2504 (Character set is unsupported). (Bug#44232)

For InnoDB tables with ROW_FORMAT = REDUNDANT, CHAR columns should be fixed-length and allow in-place updates. However, they were treated as variable-length if they contained utf8 data or NULL, preventing in-place updates. (Bug#44032)

InnoDB use of SELECT MAX(autoinc_column) could cause a crash when MySQL data dictionaries went out of sync. (Bug#44030)

In some circumstances, when a table is created with the IBMDB2I engine, the CREATE TABLE statement will return successfully but the table will not exist. (Bug#44022)

On 64-bit Windows systems, myisamchk did not handle key_buffer_size values larger than 4GB. (Bug#43940)

For user-defined utf8 collations, attempts to store values too long for a column could cause a server crash. (Bug#43827)

Invalidation of query cache entries due to table modifications could cause threads to hang inside the query cache with state “freeing items”. (Bug#43758)

EXPLAIN EXTENDED could crash for UNION queries in which the last SELECT was not parenthesized and included an ORDER BY clause. (Bug#43612)

Enabling the event scheduler from within the file specified by --init-file caused a server crash. (Bug#43587)

Multiple-table updates for InnoDB tables could produce unexpected results. (Bug#43580)

The server did not always check the return value of calls to the hash_init() function. (Bug#43572)

If the client lost the connection to the MySQL server after mysql_stmt_prepare(), the first call to mysql_stmt_execute() returned an error (as expected) but consecutive calls to mysql_stmt_execute() or mysql_stmt_close() crashed the client. (Bug#43560)

For InnoDB tables, overflow in an AUTO_INCREMENT column could cause a server crash. (Bug#43203)

For DELETE statements with ORDER BY var, where var was a global system variable with a NULL value, the server could crash. (Bug#42778)

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)

For InnoDB tables, spurious duplicate-key errors could occur when inserting into an AUTO_INCREMENT column. (Bug#42714)

mysqladmin --count=X --sleep=Y incorrectly delayed Y seconds after the last iteration before exiting. (Bug#42639)

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

For InnoDB tables, inserting into floating-point AUTO_INCREMENT columns failed. (Bug#42400)

Builds linked against OpenSSL had a memory leak in association with use of X509 certificates. (Bug#42158)

There was a race condition when changing innodb_commit_concurrency at runtime from zero to nonzero or from nonzero to zero. Now this variable cannot be changed at runtime from zero to nonzero or vice versa. The value can still be changed from one nonzero value to another. (Bug#42101)

See also Bug#45749.

SELECT ... INTO @var could produce values different from SELECT ... without the INTO clause. (Bug#42009)

mysql_zap did not work on Mac OS X. (Bug#41883)

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

A crash occurred due to a race condition between the merge table and table_cache evictions.

00000001403C452F    mysqld.exe!memcpy()[memcpy.asm:151]
00000001402A275F    mysqld.exe!ha_myisammrg::info()[ha_myisammrg.cc:854]
00000001402A2471    mysqld.exe!ha_myisammrg::attach_children()[ha_myisammrg.cc:488]
00000001402A2788    mysqld.exe!ha_myisammrg::extra()[ha_myisammrg.cc:863]
000000014015FC5D    mysqld.exe!attach_merge_children()[sql_base.cc:4135]
000000014016A4C1    mysqld.exe!open_tables()[sql_base.cc:4697]
000000014016A898    mysqld.exe!open_and_lock_tables_derived()[sql_base.cc:4956]
000000014018BB54    mysqld.exe!mysql_insert()[sql_insert.cc:613]
000000014019EDD3    mysqld.exe!mysql_execute_command()[sql_parse.cc:3066]
00000001401A2F06    mysqld.exe!mysql_parse()[sql_parse.cc:5791]
00000001401A3C1A    mysqld.exe!dispatch_command()[sql_parse.cc:1202]
00000001401A4CD7    mysqld.exe!do_command()[sql_parse.cc:857]
0000000140246327    mysqld.exe!handle_one_connection()[sql_connect.cc:1115]
00000001402B82C5    mysqld.exe!pthread_start()[my_winthread.c:85]
00000001403CAC37    mysqld.exe!_callthreadstart()[thread.c:295]
00000001403CAD05    mysqld.exe!_threadstart()[thread.c:275]
0000000077D6B69A    kernel32.dll!BaseThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...

(Bug#41212)

Shared-memory connections did not work in Vista if mysqld was started from the command line. (Bug#41190)

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 though the query had this form:

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

(Bug#41156)

For views created with a column list clause, column aliases were not substituted when selecting through the view using a HAVING clause. (Bug#40825)

Some UPDATE statements that affected no rows returned a rows-affected count of one. (Bug#40565)

mysqladmin did not have enough space allocated for tracking all variables when using --vertical or --relative with extended-status. (Bug#40395)

Partitioning a log table caused a server crash. (Bug#40281)

When using quick access methods to search for rows in UPDATE and DELETE statements, there was no check whether a fatal error had already been sent to the client while evaluating the quick condition. Consequently, a false OK (following the error) was sent to the client, causing the error to be incorrectly transformed into a warning. (Bug#40113)

A multiple-table DELETE involving a table self-join could cause a server crash. (Bug#39918)

Creating an InnoDB table with a comment containing a '#' character caused foreign key constraints to be omitted. (Bug#39793)

ALTER TABLE neglected to preserve ROW_FORMAT information from the original table, which could cause subsequent ALTER TABLE and OPTIMIZE TABLE statements to lose the row format for InnoDB tables. (Bug#39200)

The mysql option --ignore-spaces was nonfunctional. (Bug#39101)

The functions listed in Section 11.13.4.2.3, “Creating Geometry Values Using MySQL-Specific Functions”, previously accepted WKB arguments and returned WKB values. They now accept WKB or geometry arguments and return geometry values.

The functions listed in Section 11.13.4.2.2, “Creating Geometry Values Using WKB Functions”, previously accepted WKB arguments and returned geometry values. They now accept WKB or geometry arguments and return geometry values. (Bug#38990)

SHOW PROCESSLIST could access freed memory of a stored procedure run in a concurrent session. (Bug#38816)

During installation on Windows, the MySQL Instance Configuration Wizard window could be opened at a size too small to be usable. (Bug#38723)

make_binary_distribution did not always generate correct distribution names. (Bug#37808)

The server crashed when executing a prepared statement containing a duplicated MATCH() function call in the select list and ORDER BY clause; for example, SELECT MATCH(a) AGAINST('test') FROM t1 ORDER BY MATCH(a) AGAINST('test'). (Bug#37740)

The output of mysqldump --tab for views included a DROP TABLE statement without the IF EXISTS qualifier. (Bug#37377)

If a query was such as to produce the error 1054 Unknown column '...' in 'field list', using EXPLAIN EXTENDED with the query could cause a server crash. (Bug#37362)

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)

In the mysql client, using a default character set of binary caused internal commands such as DELIMITER to become case sensitive. (Bug#37268)

A Valgrind error during subquery execution was corrected. (Bug#36995)

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)

mysql_upgrade silently ignored the --basedir and --datadir options, which it accepts for backward compatibility. Now it prints a warning. (Bug#36558)

For InnoDB tables, poor cardinality statistics could result in poor query execution plans. (Bug#36513)

mysqldump --tab dumped triggers to stdout rather than to the .sql file for the corresponding table. (Bug#34861)

If the MYSQL_HISTFILE environment variable was set to /dev/null, the mysql client overwrote the /dev/null device file as a normal file. (Bug#34224)

Rows written to the slow query log could have an indeterminate Rows_examined value due to improper initialization. (Bug#34002)

mysqld_safe mishandled certain parameters if they contained spaces. (Bug#33685)

mysqlimport was not always compiled correctly to enable thread support, which is required for the --use-threads option. (Bug#32991)

mysqladmin kill did not work for thread IDs larger than 32 bits. (Bug#32457)

mysqlcheck failed to fix table names when the --fix-table-names and --all-in-1 options were both specified. (Bug#31821)

If the MySQL server was killed without the PID file being removed, attempts to stop the server with mysql.server stop waited 900 seconds before giving up. (Bug#31785)

When performing an installation on Windows using the GUI installer, the installer would fail to wait long enough during installation for the MySQL service to be installed, which would cause the installation to fail and may cause security settings, such as the root password to not be applied correctly. (Bug#30525)

mysql included extra spaces at the end of some result set lines. (Bug#29622)

Several client programs failed to interpret --skip-password as “send no password.” (Bug#28479)

The mysql client inconsistently handled NUL bytes in column data in various output formats. (Bug#28203)

mysqlimport did not correctly quote and escape table identifiers and file names. (Bug#28071)

Output from mysql --html did not encode the <, >, or & characters. (Bug#27884)

If the mysql client was built with the readline library and the .inputrc file mapped Space to the magic-space function, it became impossible to enter spaces. (Bug#27439)

mysql_convert_table_format did not prevent conversion of tables to MEMORY or BLACKHOLE tables, which could result in data loss. (Bug#27149)

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

If InnoDB reached its limit on the number of concurrent transactions (1023), it wrote a descriptive message to the error log but returned a misleading error message to the client, or an assertion failure occurred. (Bug#18828)

See also Bug#46672.