Security Fix; Partitioning: Accessing a table having user-defined partitioning when the server SQL mode included
ONLY_FULL_GROUP_BYcaused 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;
Security Fix: The
strxnmov()library function could write a null byte after the end of the destination buffer. (Bug #44834)
InnoDBtables, 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)
Important Change; Replication: When using
MIXEDbinary logging format, a statement that changes both nontransactional and transactional tables must be written to the binary log whenever there are changes to nontransactional 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
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.
Partitioning: Truncating a partitioned
MyISAMtable did not reset the
AUTO_INCREMENTvalue. (Bug #35111)
SHOW SLAVE STATUSconnection 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
NULLterminators, causing the error Conditional jump or move depends on uninitialized value(s). (Bug #45511)
References: See also Bug #43076.
Replication: For replication of a stored procedure that uses the
gbkcharacter 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.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, Bug #11752675)
References: See also Bug #37148, Bug #11748696, Bug #46166, Bug #11754544.
--databaseoption for mysqlbinlog was ignored when using the row-based logging format. (Bug #42941)
Replication: Statements using
LIMITgenerated 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)
References: See also Bug #46265, Bug #42415. This bug was introduced by Bug #34768.
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
IBMDB2Istorage engine with the
ibmdb2i_create_index_optionoption set to 1, creating an
IBMDB2Itable with a primary key should produce an additional index that uses EBCDIC hexadecimal sorting, but this index was not created. (Bug #45983)
Some collations were causing
IBMDB2Ito report inaccurate key range estimations to the optimizer for
LIKEclauses that select substrings. This can be seen by running
EXPLAIN. This problem primarily affects multibyte 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)
Inserting data into a table using the
maccecharacter set with the
IBMDB2Istorage engine failed. (Bug #45793)
There was a race condition when changing
innodb_commit_concurrencyat runtime to the value
DEFAULT. (Bug #45749)
References: See also Bug #42101.
Performing an empty XA transaction caused the server to crash for the next XA transaction. (Bug #45548)
An assertion failure could occur if
InnoDBtried to unlock a record when the clustered index record was unknown. (Bug #45357)
--enable-options (for example,
--enable-innodb) did not work correctly. (Bug #45336)
References: See also Bug #19027.
The optimizer mishandled “impossible range” conditions and returned empty results due to an uninitialized variable. (Bug #45266)
The mysql client could misinterpret some character sequences as commands under some circumstances. (Bug #45236)
InnoDBrecovery 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_INCREMENTcolumn and a
BEFOREtrigger that used the
INSERT ... SELECTconstruct, an internal flag was not reset properly. This led to a crash the next time the table was opened again. (Bug #44653)
configure.incontained references to literal instances of nm and
libc, rather than to variables parameterized for the proper values on the current platform. (Bug #42721)
configure.indid not properly check for the
pthread_setschedprio()function. (Bug #42599)
SHOW ERRORSreturned an empty result set after an attempt to drop a nonexistent table. (Bug #42364)
A workaround for a Sun Studio bug was instituted. (Bug #41710)
For queries with a sufficient number of subqueries in the
FROMclause 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 selecterror, as though the query had this form:
SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM ...
UPDATEstatements that affected no rows returned a rows-affected count of one. (Bug #40565)
Valgrind warnings that occurred for
SHOW TABLE STATUSwith
InnoDBtables were silenced. (Bug #38479)
In the mysql client, if the server connection was lost during repeated
statuscommands, the client failed to detect this and command output would be inconsistent. (Bug #37274)
A Valgrind error during subquery execution was corrected. (Bug #36995)
When invoked to start multiple server instances, mysqld_multi sometimes failed to start them all due to not changing location into the base directory for each instance. (Bug #36654)
Rows written to the slow query log could have an indeterminate
Rows_examinedvalue due to improper initialization. (Bug #34002)
Renaming a column that appeared in a foreign key definition did not update the foreign key definition with the new column name. (Bug #21704)