Incompatible Change: The
SHA2()
function now returns a character string with the connection character set and collation. Previously, it returned a binary string. This is the same change made for several other encryption functions in MySQL 5.5.3. (Bug #54661)InnoDB: The mechanism that checks if there is enough space for redo logs was improved, reducing the chance of encountering this message:
ERROR: the age of the last checkpoint is
. (Bug #39168)x
, which exceeds the log group capacityy
InnoDB: Improved performance and scalability on Windows systems, especially for Windows Vista and higher. Re-enabled the use of atomic instructions on Windows systems. For Windows Vista and higher, reduced the number of event handles used. To compile on Windows systems now requires Windows SDK v6.0 or later; either upgrade to Visual Studio 2008 or 2010, or for Visual Studio 2005, install Windows SDK Update for Windows Vista. (Bug #22268)
REPAIR TABLE
andOPTIMIZE TABLE
table now catch and throw any errors that occur while copying table statistics from the old corrupted file to newly created file. For example. if the user ID of the owner of the.frm
,.MYD
, or.MYI
file is different from the user ID of the mysqld process,REPAIR TABLE
andOPTIMIZE TABLE
generate a "cannot change ownership of the file" error unless mysqld is started by theroot
user. (Bug #61598, Bug #13600058)-
Previously,
MySQL-shared-compat
RPMs for Linux contained both the current and previous client library versions for the target platform. Thus, the package contents overlapped withMySQL-shared
RPMs, which contain only the current client library version. This can result in problems in two cases:When the
MySQL-shared
RPM is installed but later it is determined that theMySQL-shared-compat
RPM is needed (an application is installed that was linked against an older client library). Installing theMySQL-shared-compat
RPM results in a conflict because both include the current library version. This can be overcome by using the--force
option to RPM, or by first uninstalling theMySQL-shared
RPM (which breaks dependencies).When the
MySQL-shared-compat
RPM is installed, but old applications that require it are removed or upgraded to the current library version. In this case,MySQL-shared-compat
cannot be replaced withMySQL-shared
as long as current applications are installed. This can be overcome by using the--force
option to RPM, which incurs the risk of breaking dependencies.
Now the
MySQL-shared-compat
RPMs include only older client library versions and no longer include the current version, so that theMySQL-shared
andMySQL-shared-compat
RPM contents no longer overlap. TheMySQL-shared-compat
RPM can be installed even if theMySQL-shared
RPM is installed, without producing conflicts related to the current library version. TheMySQL-shared-compat
RPM can be uninstalled when old applications are removed or upgraded to the current library version, without breaking applications that already use the current library version.If you previously installed the
MySQL-shared-compat
RPM because you needed both the current and previous libraries, you should install both theMySQL-shared
andMySQL-shared-compat
RPMs now. (Bug #56150)References: See also: Bug #12368215.
Overhead for the Performance Schema interface was reduced. (Bug #55087)
Within stored programs,
LIMIT
clauses now permit integer-valued routine parameters or local variables as parameters. (Bug #11918)Code was removed for the following no-longer-supported platforms: NetWare, MS-DOS, VMS, QNX, and 32-bit SPARC.
Security Fix; InnoDB: After changing the values of the
innodb_file_format
orinnodb_file_per_table
configuration parameters, DDL statements could cause a server crash. (Bug #55039)Security Fix: During evaluation of arguments to extreme-value functions such as
LEAST()
andGREATEST()
, type errors did not propagate properly, causing the server to crash. (Bug #55826)Security Fix: The server could crash after materializing a derived table that required a temporary table for grouping. (Bug #55568)
Security Fix: A user-variable assignment expression that is evaluated in a logical expression context can be precalculated in a temporary table for
GROUP BY
. However, when the expression value is used after creation of the temporary table, it was re-evaluated, not read from the table, and a server crash resulted. (Bug #55564)Security Fix: Joins involving a table with a unique
SET
column could cause a server crash. (Bug #54575)Security Fix: Pre-evaluation of
LIKE
predicates during view preparation could cause a server crash. (Bug #54568, Bug #11762026)Security Fix: Incorrect handling of
NULL
arguments could lead to a crash forIN()
orCASE
operations whenNULL
arguments were either passed explicitly as arguments (forIN()
) or implicitly generated by theWITH ROLLUP
modifier (forIN()
andCASE
). (Bug #54477)Security Fix:
GROUP_CONCAT()
andWITH ROLLUP
together could cause a server crash. (Bug #54476)Security Fix: Queries could cause a server crash if the
GREATEST()
orLEAST()
function had a mixed list of numeric andLONGBLOB
arguments, and the result of such a function was processed using an intermediate temporary table. (Bug #54461)Security Fix: A malformed argument to the
BINLOG
statement could result in Valgrind warnings or a server crash. (Bug #54393)Security Fix: After
ALTER TABLE
was used on a temporary transactional table locked byLOCK TABLES
, any later attempts to executeLOCK TABLES
orUNLOCK TABLES
caused a server crash. (Bug #54117)Security Fix: Use of
TEMPORARY
InnoDB
tables with nullable columns could cause a server crash. (Bug #54044)Security Fix: Queries with nested joins could cause an infinite loop in the server when used from stored procedures and prepared statements. (Bug #53544)
Security Fix: Using
EXPLAIN
with queries of the formSELECT ... UNION ... ORDER BY (SELECT ... WHERE ...)
could cause a server crash. (Bug #52711)Security Fix: A security bug was fixed. (Bug #49124)
-
Incompatible Change; Replication: As of MySQL 5.5.6, handling of
CREATE TABLE IF NOT EXISTS ... SELECT
statements has been changed for the case that the destination table already exists:Previously, for
CREATE TABLE IF NOT EXISTS ... SELECT
, MySQL produced a warning that the table exists, but inserted the rows and wrote the statement to the binary log anyway. By contrast,CREATE TABLE ... SELECT
(withoutIF NOT EXISTS
) failed with an error, but MySQL inserted no rows and did not write the statement to the binary log.MySQL now handles both statements the same way when the destination table exists, in that neither statement inserts rows or is written to the binary log. The difference between them is that MySQL produces a warning when
IF NOT EXISTS
is present and an error when it is not.
This change in handling of
IF NOT EXISTS
results in an incompatibility for statement-based replication from a MySQL 5.1 master with the original behavior and a MySQL 5.5 slave with the new behavior. Suppose thatCREATE TABLE IF NOT EXISTS ... SELECT
is executed on the master and the destination table exists. The result is that rows are inserted on the master but not on the slave. (Row-based replication does not have this problem.)To address this issue, statement-based binary logging for
CREATE TABLE IF NOT EXISTS ... SELECT
is changed in MySQL 5.1 as of 5.1.51:If the destination table does not exist, there is no change: The statement is logged as is.
If the destination table does exist, the statement is logged as the equivalent pair of
CREATE TABLE IF NOT EXISTS
andINSERT ... SELECT
statements. (If theSELECT
in the original statement is preceded byIGNORE
orREPLACE
, theINSERT
becomesINSERT IGNORE
orREPLACE
, respectively.)
This change provides forward compatibility for statement-based replication from MySQL 5.1 to 5.5 because when the destination table exists, the rows will be inserted on both the master and slave. To take advantage of this compatibility measure, the 5.1 server must be at least 5.1.51 and the 5.5 server must be at least 5.5.6.
To upgrade an existing 5.1-to-5.5 replication scenario, upgrade the master first to 5.1.51 or higher. Note that this differs from the usual replication upgrade advice of upgrading the slave first.
A workaround for applications that wish to achieve the original effect (rows inserted regardless of whether the destination table exists) is to use
CREATE TABLE IF NOT EXISTS
andINSERT ... SELECT
statements rather thanCREATE TABLE IF NOT EXISTS ... SELECT
statements.Along with the change just described, the following related change was made: Previously, if an existing view was named as the destination table for
CREATE TABLE IF NOT EXISTS ... SELECT
, rows were inserted into the underlying base table and the statement was written to the binary log. As of MySQL 5.1.51 and 5.5.6, nothing is inserted or logged. (Bug #47442, Bug #47132, Bug #48814, Bug #49494) -
Incompatible Change: Several changes were made to Performance Schema tables:
The
SETUP_OBJECTS
table was removed.The
PROCESSLIST
table was renamed toTHREADS
.The
EVENTS_WAITS_SUMMARY_BY_EVENT_NAME
table was renamed toEVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME
.
(Bug #55416)
-
Incompatible Change: Handling of warnings and errors during stored program execution was problematic:
If one statement generated several warnings or errors, only the handler for the first was activated, even if another might be more appropriate. Now the server chooses the more appropriate handler.
Warning or error information could be lost.
(Bug #36185, Bug #5889, Bug #9857, Bug #23032)
-
Incompatible Change: If the server was started with
character_set_server
set toutf16
, it crashed during full-text stopword initialization. Now the stopword file is loaded and searched usinglatin1
ifcharacter_set_server
isucs2
,utf16
, orutf32
.If any table was created with
FULLTEXT
indexes while the server character set wasucs2
,utf16
, orutf32
, it should be repaired using this statement:REPAIR TABLE tbl_name QUICK;
(Bug #32391)
Important Change; Replication: The
LOAD DATA
statement is now considered unsafe for statement-based replication. When using statement-based logging mode, the statement now produces a warning; when using mixed-format logging, the statement is made using the row-based format. (Bug #34283)Performance; InnoDB: The setting
innodb_change_buffering=all
could produce slower performance for some operations than the previous default,innodb_change_buffering=inserts
. (Bug #54914)Performance; InnoDB: An
EXPLAIN
plan for anInnoDB
table could vary greatly in the estimated cost for aBETWEEN
clause. (Bug #53761)InnoDB: An assertion was raised if (1) an
InnoDB
table was created usingCREATE TABLE ... SELECT
where the query used anINFORMATION_SCHEMA
table and a view existed in the database; or (2) any statement that modified anInnoDB
table had a subquery referencing anINFORMATION_SCHEMA
table. (Bug #55973)InnoDB: The
InnoDB
storage engine was not included in the default installation when using the configure script. (Bug #55547)InnoDB: For an
InnoDB
table with an auto-increment column, the server could crash if the first statement that references the table after a server restart is aSHOW CREATE TABLE
statement. (Bug #55277)InnoDB: The mysql_config tool did not output the requirement for the
aio
library formysqld-libs
. (Bug #55215)InnoDB: Some memory used for
InnoDB
asynchronous I/O was not freed at shutdown. (Bug #54764)InnoDB: Implementation of the 64-bit
dulint
structure inInnoDB
was not optimized for 64-bit processors, resulting in excessive storage and reduced performance. (Bug #54728)InnoDB: The output from the
SHOW ENGINE INNODB STATUS
command now includes information about “spin rounds” for RW-locks (both shared and exclusive locks). (Bug #54726)InnoDB: An
ALTER TABLE
statement could convert anInnoDB
compressed table (withrow_format=compressed
) back to an uncompressed table (withrow_format=compact
). (Bug #54679)InnoDB:
InnoDB
could issue an incorrect message on startup, if tables were created under the settinginnodb_file_per_table=ON
. The message was of the formInnoDB: Warning: allocated tablespace
. If you encounter this message after upgrading, create ann
, old maximum was 0InnoDB
table withinnodb_file_per_table = ON
and restart the server. The message should not be displayed any more. If you continue to encounter this message, or if you get it and haven't used a version without this fix, you might have corruption in your shared tablespace. If so, back up and reload your data. (Bug #54658)InnoDB: For debug builds, the database server could crash when renaming a table that had active transactions. (Bug #54453)
InnoDB: The server could crash during the recovery phase of startup, if it previously crashed while inserting
BLOB
or other large columns that use off-page storage into anInnoDB
table created withROW_FORMAT=REDUNDANT
orROW_FORMAT=COMPACT
. (Bug #54408)InnoDB: For an
InnoDB
table created withROW_FORMAT=COMPRESSED
orROW_FORMAT=DYNAMIC
, a query using theREAD UNCOMMITTED
isolation level could cause the server to stop with an assertion error, ifBLOB
or other large columns that use off-page storage were being inserted at the same time. (Bug #54358)InnoDB: If a session executing
TRUNCATE TABLE
on anInnoDB
table was killed duringopen_tables()
, an assertion could be raised. (Bug #53757)InnoDB: The
Lock_time
field in the slow query log now reports a larger value, including the time forInnoDB
lock waits at the statement level. (Bug #53496)InnoDB: Misimplementation of the
os_fast_mutex_trylock()
function inInnoDB
resulted in unnecessary blocking and reduced performance. (Bug #53204)InnoDB:
InnoDB
could not create tables that used theutf32
character set. (Bug #52199)InnoDB: Performing large numbers of
RENAME TABLE
statements caused excessive memory use. (Bug #47991)Partitioning: With
innodb_thread_concurrency = 1
,ALTER TABLE ... REORGANIZE PARTITION
andSELECT
could deadlock. There were unreleased latches in theALTER TABLE ... REORGANIZE PARTITION
thread which were needed by theSELECT
thread to be able to continue. (Bug #54747)-
Partitioning: An
ALTER TABLE ... ADD PARTITION
statement run concurrently with a read lock caused spuriousER_TABLE_EXISTS_ERROR
andER_NO_SUCH_TABLE
errors on subsequent attempts. (Bug #53676)References: See also: Bug #53770.
-
Partitioning:
UPDATE
andINSERT
statements affecting partitioned tables performed poorly when using row-based replication. (Bug #52517)References: This issue is a regression of: Bug #39084.
Partitioning:
INSERT ON DUPLICATE KEY UPDATE
statements performed poorly on tables having many partitions. The handler function for reading a row from a specific index was not optimized in the partitioning handler. (Bug #52455)-
Partitioning:
ALTER TABLE ... TRUNCATE PARTITION
, when called concurrently with transactional DML on the table, was executed immediately and did not wait for the concurrent transaction to release locks. As a result, theALTER TABLE
statement was written into the binary log before the DML statement, which led to replication failures when using row-based logging. (Bug #49907)References: See also: Bug #42643.
Partitioning: When the storage engine used to create a partitioned table was disabled, attempting to drop the table caused the server to crash. (Bug #46086)
Replication: When using the row-based logging format, a failed
CREATE TABLE ... SELECT
statement was written to the binary log, causing replication to break if the failed statement was later re-run on the master. In such cases, aDROP TABLE ... IF EXIST
statement is now logged in the event that aCREATE TABLE ... SELECT
fails. (Bug #55625)Replication: When using the row-based logging format, a
SET PASSWORD
statement was written to the binary log twice. (Bug #55452)Replication: When closing temporary tables, after the session connection was already closed, if the writing of the implicit
DROP TABLE
statement into the binary log failed, it was possible for the resulting error to be mishandled, triggering an assertion. (Bug #55387)Replication: Executing
SHOW BINLOG EVENTS
increased the value ofmax_allowed_packet
applying to the session that executed the statement. (Bug #55322)Replication: Setting
binlog_format
toROW
, then creating and dropping a temporary table led to an assertion. (Bug #54925)-
Replication: When using mixed-format replication, changes made to a nontransactional temporary table within a transaction were not written into the binary log when the transaction was rolled back. This could lead to a failure in replication if the temporary table was used again afterwards. (Bug #54872)
References: See also: Bug #53259.
-
Replication: If
binlog_format
was explicitly switched fromSTATEMENT
toROW
following the creation of a temporary table, then on disconnection the master failed to write the expectedDROP TEMPORARY TABLE
statement into the binary log. As a consequence, temporary tables (and their corresponding files) accumulated as this scenario was repeated. (Bug #54842)References: See also: Bug #52616.
-
Replication: If the SQL thread was started while the I/O thread was performing rotation of the relay log, the two threads could begin to race for the same I/O cache, leading to a server crash. (Bug #54509)
References: See also: Bug #50364.
-
Replication: Two related issues involving temporary tables and transactions were introduced by a fix made in MySQL 5.1.37:
When a temporary table was created or dropped within a transaction, any failed statement that following the
CREATE TEMPORARY TABLE
orDROP TEMPORARY TABLE
statement triggered a rollback, which caused the slave to diverge from the master.When a
CREATE TEMPORARY TABLE ... SELECT * FROM ...
statement was executed within a transaction in which only tables using transactional storage engines were used and the transaction was rolled back at the end, the changes—including the creation of the temporary table—were not written to the binary log.
The current fix restores the correct behavior in both of these cases. (Bug #53560)
References: This issue is a regression of: Bug #43929.
-
Replication: The value of
binlog_direct_non_transactional_updates
had no effect on statements mixing transactional tables and nontransactional tables, or mixing temporary tables and nontransactional tables.As part of the fix for this issue, updates to temporary tables are now handled as transactional or nontransactional according to their storage engine types. (In effect, the current fix reverts a change made previously as part of the fix for Bug #53259.)
In addition, unsafe mixed statements (that is, statements which access transactional table as well nontransactional or temporary tables, and write to any of them) are now handled as transactional when the statement-based logging format is in use. (Bug #53452)
References: See also: Bug #51894, Bug #53259.
-
Replication: A number of statements generated unnecessary warnings as potentially unsafe statements. (Due to the fix for Bug #51894, a temporary table is treated in this context as a transactional table, so that any mixed statement such as
t_innodb
+t_myisam
ort_temp
+t_myisam
is flagged as unsafe.)To reduce the number of spurious warnings produced when this happened, some of the criteria used to classify a statements as safe or unsafe have been changed. For more information about handling of mixed statements, see Transactional, nontransactional, and mixed statements. (Bug #53259)
References: See also: Bug #51894, Bug #53452, Bug #54872.
-
Replication: When
binlog_format=STATEMENT
, any statement that is flagged as being unsafe, possibly causing the slave to go out of sync, generates a warning. This warning is written to the server log, the warning count is returned to the client in the server's response, and the warnings are accessible throughSHOW WARNINGS
.The current bug affects only the counts for warnings to the client and that are visible through
SHOW WARNINGS
; it does not affect which warnings are written to the log. The current issue came about because the fix for an earlier issue caused warnings for substatements to be cleared whenever a new substatement was started. However, this suppressed warnings for unsafe statements in some cases. Now, such warnings are no longer cleared. (Bug #50312)References: This issue is a regression of: Bug #36649.
Replication: Replication could break if a transaction involving both transactional and nontransactional tables was rolled back to a savepoint. It broke if a concurrent connection tried to drop a transactional table which was locked after the savepoint was set. This
DROP TABLE
completed whenROLLBACK TO SAVEPOINT
was executed because the lock on the table was dropped by the transaction. When the slave later tried to apply the binary log events, it failed because the table had already been dropped. (Bug #50124)Replication: When
CURRENT_USER()
orCURRENT_USER
was used to supply the name and host of the affected user or of the definer in any of the statementsDROP USER
,RENAME USER
,GRANT
,REVOKE
, andALTER EVENT
, the reference toCURRENT_USER()
orCURRENT_USER
was not expanded when written to the binary log. This resulted inCURRENT_USER()
orCURRENT_USER
being expanded to the user and host of the slave SQL thread on the slave, thus breaking replication. NowCURRENT_USER()
andCURRENT_USER
are expanded prior to being written to the binary log in such cases, so that the correct user and host are referenced on both the master and the slave. (Bug #48321)Microsoft Windows: The Windows MSI installer failed during installation to preserve custom settings, such as the configured data directory. (Bug #55169)
Microsoft Windows: Use of
uint
intypelib.h
caused compilation problems in Windows. This was changed tounsigned int
. (Bug #52959)Microsoft Windows: The
mysql-debug.pdb
supplied with releases did not match the corresponding mysqld.exe. (Bug #52850)Microsoft Windows: The
PERFORMANCE_SCHEMA
database was not correctly created and populated on Windows. (Bug #52809)Solaris: The
-features=no%except
option was missing from the build for Solaris/x86. (Bug #55250)Solaris: A signal-handler redefinition for
SIGUSR1
was removed. The redefinition could cause the server to encounter a kernel deadlock on Solaris when there are many active threads. Other POSIX platforms might also be affected. (Bug #54667)-
For the general query log and slow query log, logging to tables incurred excessive overhead beginning with MySQL 5.1.21. This overhead has been eliminated. (Bug #11747038, Bug #30414)
References: See also: Bug #29129.
After an RPM installation, mysqld would be started with the
root
user, rather than themysql
user. (Bug #56574)The embedded server raised an assertion when it attempted to load plugins. (Bug #56085)
FORMAT()
did not respect the decimal point character if the locale was changed and always returned an ASCII value. (Bug #55912)CMake produced bad dependencies for the
sql/lex_hash.h
file during configuration. (Bug #55842)mysql_upgrade did not handle the
--ssl
option properly. (Bug #55672)Using
MIN()
orMAX()
on a column containing the maximumTIME
value caused a server crash. (Bug #55648)Incorrect handling of user variable assignments as subexpressions could lead to incorrect results or server crashes. (Bug #55615)
The default compiler options for OS X 10.5 were set incorrectly. (Bug #55601)
The server was not checking for errors generated during the execution of
Item::val_xxx()
methods when copying data to a group, order, or distinct temp table's row. (Bug #55580)ORDER BY
clauses that included user-variable expressions could raise a debug assertion. (Bug #55565)-
SHOW CREATE TRIGGER
took a stronger metadata lock than required. This caused the statement to be blocked unnecessarily. For example,LOCK TABLES ... WRITE
in one session blockedSHOW CREATE TRIGGER
in another session.Also, a
SHOW CREATE TRIGGER
statement issued inside a transaction did not release its metadata locks at the end of statement execution. Consequently,SHOW CREATE TRIGGER
was able to block other sessions from accessing the table (for example, usingALTER TABLE
). (Bug #55498) A single-table
DELETE
ordered by a column that had a hash-type index could raise an assertion or cause a server crash. (Bug #55472)A call to
mysql_library_init()
following a call tomysql_library_end()
caused a client crash. (Bug #55345)A statement that was aborted by
KILL QUERY
while it waited on a metadata lock could raise an assertion in debug builds, or send OK to the client instead ofER_QUERY_INTERRUPTED
in regular builds. (Bug #55223)GROUP BY
operations usedmax_sort_length
inconsistently. (Bug #55188)InnoDB
produced no warning at startup about illegalinnodb_file_format_check
values. (Bug #55095)IF()
with a subquery argument could raise a debug assertion for debug builds under some circumstances. (Bug #55077)Building MySQL on Solaris 8 x86 failed when using Sun Studio due to gcc inline assembly code. (Bug #55061)
When upgrading an existing install with an RPM on Linux, the MySQL server might not have been restarted properly. This was due to a naming conflict when upgrading from a
community
named RPM. Previous installations are now correctly removed, the MySQL initialization script is recreated, and the MySQL server is restarted as normal. (Bug #55015)The
thread_concurrency
system variable was unavailable on non-Solaris systems. (Bug #55001)mysqld_safe contained a syntax error that prevented it from restarting the server. (Bug #54991)
If audit plugins were installed that were interested in
MYSQL_AUDIT_GENERAL_CLASS
events and the general query log was disabled, failedINSTALL PLUGIN
orUNINSTALL PLUGIN
statements caused a server crash. (Bug #54989)Some functions did not calculate their
max_length
metadata value correctly. (Bug #54916)A
SHOW CREATE TABLE
statement issued inside a transaction did not release its metadata locks at the end of statement execution. Consequently,SHOW CREATE TABLE
was able to block other sessions from accessing the table (for example, usingALTER TABLE
). (Bug #54905)INFORMATION_SCHEMA.ENGINES
andSHOW ENGINES
describedMyISAM
as the default storage engine, but this is not true as of MySQL 5.5.5. (Bug #54832)The
MERGE
storage engine tried to use memory mapping on the underlyingMyISAM
tables even on platforms that do not support it and even whenmyisam_use_mmap
was disabled. This led to a hang forINSERT INTO ... SELECT FROM
statements that selected from aMyISAM
table into aMERGE
table that contained the sameMyISAM
table. (Bug #54811, Bug #50788)Incorrect error handling could result in an
OPTIMIZE TABLE
crash. (Bug #54783)Performance Schema event collection for a thread could “leak” from one connection to another if the thread was used for one connection, then cached, then reused for another connection. (Bug #54782)
In debug builds, an assertion could be raised when the server tried to send an OK packet to the client after having failed to detect errors during processing of the
WHERE
condition of anUPDATE
statement. (Bug #54734)In a slave SQL thread or Event Scheduler thread, the
SLEEP()
function could not sleep more than five seconds. (Bug #54729)SET sql_select_limit = 0
did not work. (Bug #54682)Assignments of the
PASSWORD()
orOLD_PASSWORD()
function to a user variable did not preserve the character set of the function return value. (Bug #54668)Queries that named view columns in a
GROUP BY
clause could cause a server crash. (Bug #54515)The Performance Schema displayed spurious startup error messages when the server was run in bootstrap mode. (Bug #54467)
For distributions built with CMake rather than the GNU autotools, mysql lacked
pager
support, and some scripts were built without the execute bit set. (Bug #54466, Bug #54129)The server failed to disregard sort order for some zero-length tuples, leading to an assertion failure. (Bug #54459)
A join with an aggregated function and impossible
WHERE
condition returned an extra row. (Bug #54416)Errors during processing of
WHERE
conditions inHANDLER ... READ
statements were not detected, so the handler code still tried to send EOF to the client, raising an assertion. (Bug #54401)If a session tried to drop a database containing a table opened with
HANDLER
in another session, anyDATABASE
statement (CREATE
,DROP
,ALTER
) executed by that session produced a deadlock. (Bug #54360)Deadlocks involving
INSERT DELAYED
statements were not detected. The server could crash if the delayed handler thread was killed due to a conflicting shared metadata lock. (Bug #54332)After
ALTER TABLE
was used on a temporary transactional table locked byLOCK TABLES
, any later attempts to executeLOCK TABLES
orUNLOCK TABLES
caused a server crash. (Bug #54117)INSERT IGNORE INTO ... SELECT
statements could raise a debug assertion. (Bug #54106)SHOW CREATE EVENT
released all metadata locks held by the current transaction. This invalidated any existing savepoints and raised an assertion ifROLLBACK TO SAVEPOINT
was executed. (Bug #54105)A client could supply data in chunks to a prepared statement parameter other than of type
TEXT
orBLOB
using themysql_stmt_send_long_data()
C API function (orCOM_STMT_SEND_LONG_DATA
command). This led to a crash because other data types are not valid for long data. (Bug #54041)mysql_secure_installation did not properly identify local accounts and could incorrectly remove nonlocal
root
accounts. (Bug #54004)A client with automatic reconnection enabled saw the error message
Lost connection to MySQL server during query
if the connection was lost between themysql_stmt_prepare()
andmysql_stmt_execute()
C API functions. However,mysql_stmt_errno()
returned 0, not the corresponding error number 2013. (Bug #53899)INFORMATION_SCHEMA.COLUMNS
reported incorrect precision forBIGINT UNSIGNED
columns. (Bug #53814)-
The patch for Bug #36569 caused performance regressions and incorrect execution of some
UPDATE
statements. (Bug #53737, Bug #53742)References: See also: Bug #36569.
Missing Performance Schema tables were not reported in the error log at server startup. (Bug #53617)
mysql_upgrade could incorrectly remove
TRIGGER
privileges. (Bug #53613)SHOW ENGINE PERFORMANCE_SCHEMA STATUS
underreported the amount of memory allocated by the Performance Schema. (Bug #53566)Portability problems in
SHOW STATUS
could lead to incorrect results on some platforms. (Bug #53493)Builds of MySQL generated a large number of warnings. (Bug #53445)
Performance Schema header files were not installed in the correct directory. (Bug #53255)
The server could crash when processing subqueries with empty results. (Bug #53236)
With
lower_case_table_names
set to a nonzero value, searches for table or database names inINFORMATION_SCHEMA
tables could produce incorrect results. (Bug #53095)The
large_pages
system variable was tied to the--large-files
command-line option, not the--large-pages
option. (Bug #52716)Attempts to access a nonexistent Performance Schema table resulted in a misleading error message. (Bug #52586)
The ABI check for MySQL failed to compile with gcc 4.5. (Bug #52514)
The Performance Schema could enter an infinite loop if required to create a large number of mutex instances. (Bug #52502)
mysql_secure_installation sometimes failed to locate the mysql client. (Bug #52274)
Some queries involving
GROUP BY
and a function that returnedDATE
raised a debug assertion. (Bug #52159)If a symbolic link was used in a file path name, the Performance Schema did not resolve all file I/O events to the same name. (Bug #52134)
PARTITION BY KEY
on autf32
ENUM
column raised a debugging assertion. (Bug #52121, Bug #11759782)A pending
FLUSH TABLES
statement unnecessarily aborted transactions. (Bug #52117)tbl_list
WITH READ LOCK-
FLUSH TABLES WITH READ LOCK
in one session andFLUSH TABLES
in another session were mutually exclusive.tbl_list
WITH READ LOCKThis bug fix involved several changes to the states displayed by
SHOW PROCESSLIST
:Table lock
was replaced withWaiting for table level lock
.Waiting for table
andFlushing tables
were replaced withWaiting for table flush
.These states are new:
Waiting for global metadata lock
,Waiting for schema metadata lock
,Waiting for stored function metadata lock
,Waiting for stored procedure metadata lock
,Waiting for table metadata lock
.
(Bug #52044)
Reading a
ucs2
data file withLOAD DATA
was subject to three problems. 1) Incorrect parsing of the file asucs2
data, resulting in incorrect length of the parsed string. This is fixed by truncating the invalid trailing bytes (incomplete multibyte characters) when reading from the file. 2) Reads from a properucs2
file did not recognize newline characters. This is fixed by first checking whether a byte is a newline (or any other special character) before reading it as a part of a multibyte character. 3) When using user variables to hold column data, the character set of the user variable was set incorrectly to the database charset. This is fixed by setting it to the character set specified in theLOAD DATA
statement, if any. (Bug #51876)XA START
had a race condition that could cause a server crash. (Bug #51855)The results of some
ORDER BY ... DESC
queries were sorted incorrectly. (Bug #51431)Index Merge
between three indexes could return incorrect results. (Bug #50389)MIN()
andMAX()
returned incorrect results forDATE
columns if the set of values included'0000-00-00'
. (Bug #49771)Searches in
INFORMATION_SCHEMA
tables for rows matching a nonexistent database produced an error instead of an empty query result. (Bug #49542)DROP DATABASE
failed if there was aTEMPORARY
table with the same name as a non-TEMPORARY
table in the database. (Bug #48067)-
An assertion occurred in
ha_myisammrg.cc
line 1137:DBUG_ASSERT(this->file->children_attached);
The problem was found while running RQG tests and the assertion occurred during
REPAIR
,OPTIMIZE
, andANALYZE
operations. (Bug #47633) -
The optimization method of the
ARCHIVE
storage engine did not preserve the.frm
file embedded in the.ARZ
file when rewriting the.ARZ
file for optimization. This meant anARCHIVE
table that had been optimized could not be discovered.The
ARCHIVE
engine stores the.frm
file in the.ARZ
file so it can be transferred from machine to machine without also needing to copy the.frm
file. The engine subsequently restores the embedded.frm
during discovery. (Bug #45377) With
character_set_connection
set toutf16
orutf32
,CREATE TABLE t1 AS SELECT HEX() ...
caused a server crash. (Bug #45263)The
my_like_range_
functions returned badly formed maximum strings for Asian character sets, which caused problems for storage engines. (Bug #45012)xxx
()A debugging assertion could be raised after a write failure to a closed socket. (Bug #42496)
Enumeration plugin variables were subject to a type-casting error, causing inconsistent results between different platforms. (Bug #42144)
Sort-
index_merge
for join tables other than the first table used excessive memory. (Bug #41660)DROP TABLE
held a lock duringunlink()
file system operations, causing performance problems ifunlink()
took a long time. (Bug #41158)Rows inserted in a table by one session were not immediately visible to another session that queried the table, even if the insert had committed. (Bug #37521)
-
Statements of the form
UPDATE ... WHERE ... ORDER BY
used afilesort
even when not required.Prior to this fix, index hints were accepted for
UPDATE
statements but were ignored. Now they are used. (Bug #36569)References: See also: Bug #53737, Bug #53742.
-
Reading from a temporary
MERGE
table, with two nontemporary childMyISAM
tables, resulted in the error:ERROR 1168 (HY000): Unable to open underlying table which is differently defined or of non-MyISAM type or doesn't exist
(Bug #36171)
safemalloc
was excessively slow under certain conditions and has been removed. The--skip-safemalloc
server option has also been removed, and the--with-debug=full
configuration option is no different from--with-debug
. (Bug #34043)Threads that were calculating the estimated number of records for a range scan did not respond to the
KILL
statement. That is, if arange
join type is possible (even if not selected by the optimizer as a join type of choice and thus not shown byEXPLAIN
), the query in thestatistics
state (shown by theSHOW PROCESSLIST
) did not respond to theKILL
statement. (Bug #25421)Problems in the atomic operations implementation could lead to server crashes. (Bug #22320, Bug #52261)