The world's most popular open source database
Functionality added or changed:
Incompatible Change:
In MySQL 5.1.6, when log tables were implemented, the default
log destination for the general query and slow query log was
TABLE. This default has been changed to
FILE, which is compatible with MySQL 5.0, but
incompatible with earlier releases of MySQL 5.1 from 5.1.6 to
5.1.20. If you are upgrading from MySQL 5.0 to this release, no
logging option changes should be necessary. However, if you are
upgrading from 5.1.6 through 5.1.20 to this release and were
using TABLE logging, use the
--log-output=TABLE option explicitly to
preserve your server's table-logging behavior.
In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993)
Incompatible Change:
The server now includes dtoa, a library for
conversion between strings and numbers by David M. Gay. In
MySQL, this library provides the basis for improved conversion
between string or DECIMAL values
and approximate-value (FLOAT/DOUBLE) numbers:
Consistent conversion results across platforms, which eliminates, for example, Unix versus Windows conversion differences.
Accurate representation of values in cases where results previously did not provide sufficient precision, such as for values close to IEEE limits.
Conversion of numbers to string format with the best
possible precision. The precision of dtoa
is always the same or bettter than that of the standard C
library functions.
Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision.
For additional information about the properties of
dtoa conversions, see
Section 11.2.2, “Type Conversion in Expression Evaluation”.
See also Bug#12860, Bug#21497, Bug#26788, Bug#24541, Bug#34015
Important Change: MySQL Cluster: Packaging:
Beginning with this release, standard MySQL 6.0 binaries are no
longer built with support for the NDBCLUSTER
storage engine, and the NDBCLUSTER code
included in 6.0 mainline sources is no longer guaranteed to be
maintained or supported. Those using MySQL Cluster in MySQL
6.0.4 and earlier MySQL 6.0 mainline releases should upgrade to
MySQL Cluster NDB 6.2.15 or a later MySQL Cluster NDB 6.2 or 6.3
release.
(Bug#36193)
Important Change:
Added a ROUTINE_TYPE column to the
INFORMATION_SCHEMA.PARAMETERS
table, to make it possible to distinguish like-named parameters
of stored routines and stored functions having the same names.
See Section 18.25, “The INFORMATION_SCHEMA PARAMETERS Table”, for more information.
(Bug#33106)
Replication:
Introduced the slave_exec_mode system
variable to control whether idempotent or strict mode is used
for replication conflict resolution. Idempotent mode suppresses
duplicate-key, no-key-found, and some other errors, and is
needed for circular replication, multi-master replication, and
some other complex replication setups when using MySQL Cluster.
Strict mode is the default.
(Bug#31609)
Replication:
When running the server with
--binlog-format=MIXED or
--binlog-format=STATEMENT, a query that
referred to a system variable used the slave's value when
replayed on the slave. This meant that, if the value of a system
variable was inserted into a table, the slave differed from the
master. Now, statements that refer to a system variable are
marked as “unsafe”, which means that:
When the server is using
--binlog-format=MIXED, the row-based
format is used automatically to replicate these
statements.
When the server is using
--binlog-format=STATEMENT, these
statements produce a warning.
See also Bug#34732
In the INFORMATION_SCHEMA database, the
FALCON_DATABASE_IO table was renamed to
FALCON_TABLESPACE_IO.
(Bug#35490)
For boolean options, the option-processing library now prints
additional information in the --help message:
If the option is enabled by default, the message says so and
indicates that the --skip form of the option
disables the option. This affects all compiled MySQL programs
that use the library.
(Bug#35224)
The PROCESS privilege now is
required to start or stop the InnoDB monitor
tables (see linkend="innodb-monitor"/>). Previously, no
privilege was required.
(Bug#34053)
For binary .tar.gz packages,
mysqld and other binaries now are compiled
with debugging symbols included to enable easier use with a
debugger. If you do not need debugging symbols and are short on
disk space, you can use strip to remove the
symbols from the binaries.
(Bug#33252)
Several undocumented C API functions were removed:
mysql_manager_close(),
mysql_manager_command(),
mysql_manager_connect(),
mysql_manager_fetch_line(), and
mysql_manager_init().
(Bug#31954)
The C API contained several undocumented functions that have
been removed:
mysql_disable_reads_from_master(),
mysql_disable_rpl_parse(),
mysql_enable_reads_from_master(),
mysql_enable_rpl_parse(),
mysql_master_query(),
mysql_master_send_query(),
mysql_reads_from_master_enabled(),
mysql_rpl_parse_enabled(),
mysql_rpl_probe(),
mysql_rpl_query_type(),
mysql_set_master(),
mysql_slave_query(), and
mysql_slave_send_query().
(Bug#31952)
Formerly, when the MySQL server crashed, the generated stack dump was numeric and required external tools to properly resolve the names of functions. This is not very helpful to users having a limited knowledge of debugging techniques. In addition, the generated stack trace contained only the names of functions and was formatted differently for each platform due to different stack layouts.
Now it is possible to take advantage of newer versions of the GNU C Library provide a set of functions to obtain and manipulate stack traces from within the program. On systems that use the ELF binary format, the stack trace contains important information such as the shared object where the call was generated, an offset into the function, and the actual return address. Having the function name also makes possible the name demangling of C++ functions.
The library generates meaningful stack traces on the following platforms: i386, x86_64, PowerPC, IA64, Alpha, and S390. On other platforms, a numeric stack trace is still produced, and the use of the resolve_stack_dump utility is still required. (Bug#31891)
mysqltest now has mkdir
and rmdir commands for creating and removing
directories.
(Bug#31004)
The LAST_EXECUTED column of the
INFORMATION_SCHEMA.EVENTS table now
indicates when the event started executing rather than when it
finished executing. As a result, the ENDS
column is never less than LAST_EXECUTED.
(Bug#29830)
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)
The server uses less memory when loading privileges containing table grants. (Patch provided by Google.) (Bug#25175)
Added the Uptime_since_flush_status status
variable, which indicates the number of seconds since the most
recent FLUSH STATUS statement. (Community
contribution by Jeremy Cole)
(Bug#24822)
Added the SHOW PROFILES and
SHOW PROFILE statements to
display statement profile data, and the accompanying
INFORMATION_SCHEMA.PROFILING table.
Profiling is controlled via the profiling and
profiling_history_size session variables. see
Section 12.5.6.32, “SHOW PROFILES Syntax”, and
Section 18.26, “The INFORMATION_SCHEMA PROFILING Table”. (Community contribution by
Jeremy Cole)
The profiling feature is enabled via the
--enable-community-features and
--enable-profiling options to
configure. These options are enabled by
default; to disable them, use
--disable-community-features and
--disable-profiling.
(Bug#24795)
The performance of internal functions that trim multiple spaces from strings when comparing them has been improved. (Bug#14637)
Added the SHA2() function, which
calculates the SHA-2 family of hash functions (SHA-224, SHA-256,
SHA-384, and SHA-512). (Contributed by Bill Karwin)
(Bug#13174)
The new read-only global system variables
report_host,
report_password,
report_port, and
report_user system variables provide runtime
access to the values of the corresponding
--report-host,
--report-password,
--report-port, and
--report-user options.
Formerly it was possible to specify an
innodb_flush_method value of
fdatasync to obtain the default flush
behavior of using fdatasync() for flushing.
This is no longer possible because it can be confusing that a
value of fdatasync causes use of
fsync() rather than
fdatasync().
Two new statements, BACKUP
DATABASE and RESTORE,
have been added for backup and restore operations. See
Section 6.3, “Using MySQL Backup”.
The use of InnoDB hash indexes now can be
controlled by setting the new
innodb_adaptive_hash_index system variable at
server startup. By default, this variable is enabled. See
Section 13.6.12.3, “Adaptive Hash Indexes”.
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.
The Instance Manager (mysqlmanager) has been discontinued and is no longer provided in MySQL releases.
Bugs fixed:
Important Change: Security Fix:
It was possible to circumvent privileges through the creation of
MyISAM tables employing the DATA
DIRECTORY and INDEX DIRECTORY
options to overwrite existing table files in the MySQL data
directory. Use of the MySQL data directory in DATA
DIRECTORY and INDEX DIRECTORY is
now disallowed. This is now also true of these options when used
with partitioned tables and individual partitions of such
tables.
(Bug#32167, CVE-2008-2079)
Security Fix:
A client that connects to a malicious server could be tricked by
the server into sending files from the client host to the
server. This occurs because the
libmysqlclient client library would respond
to a FETCH LOCAL FILE request from the server
even if the request is sent for statements from the client other
than LOAD DATA LOCAL INFILE. The client
library has been modified to respond to a FETCH LOCAL
FILE request from the server only if is is sent in
response to a LOAD DATA LOCAL INFILE
statement from the client.
The client library now also checks whether
CLIENT_LOCAL_FILE is set and refuses to send
a local file if not.
Binary distributions ship with the
local-infile capability enabled.
Applications that do not use this functionality should disable
it to be safe.
Important Change: Security Enhancement:
On Windows Vista and Windows Server 2008, a user without
administrative privileges does not have write permissions to the
Program Files directory where MySQL and the
associated data files are normally installed. Using data files
located in the standard Program Files
installation directory could therefore cause MySQL to fail, or
lead to potential security issues in an installed instance.
To address the problem, on Windows XP, Windows Vista and Windows
Server 2008, the datafiles and data file configuration are now
set to the Microsoft recommended AppData
folder. The AppData folder is typically
located within the user's home directory.
When upgrading an existing 5.1.23 or 6.0.4 installation of
MySQL you must take a backup of your data and configuration
file (my.ini before installing the new
version. To migrate your data, either extract the data and
re-import (using mysqldump, then upgrade
and re-import using mysql), or back up your
data, upgrade to the new version, and copy your existing data
files from your old datadir directory to
the new directory located within AppData.
Failure to back up your data and follow these procedures may lead to data loss.
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)
Partitioning: Incompatible Change: The following statements did not function correctly with corrupted or crashed tables and have been removed:
ALTER TABLE ... ANALYZE PARTITION
ALTER TABLE ... CHECK PARTITION
ALTER TABLE ... OPTIMIZE PARTITION
ALTER TABLE ... REPAIR PARTITION
ALTER TABLE ... REBUILD PARTITION is
unaffected by this change and continues to be available. This
statement and ALTER TABLE ... REORGANIZE
PARTITION may be used to analyze and optimize
partitioned tables, since these operations cause the partition
files to be rebuilt.
(Bug#20129)
Incompatible Change:
In MySQL 5.1.23, the last_errno and
last_error members of the
NET structure in
mysql_com.h were renamed to
client_last_errno and
client_last_error. This was found to cause
problems for connectors that use the internal
NET structure for error handling. The change
has been reverted.
(Bug#34655)
See also Bug#12713
Incompatible Change:
The parser accepted illegal syntax in a FOREIGN
KEY clause:
Multiple MATCH clauses.
Multiple ON DELETE clauses.
Multiple ON UPDATE clauses.
MATCH clauses specified after ON
UPDATE or ON DELETE. In case of
multiple redundant clauses, this leads to confusion, and
implementation-dependent results.
These illegal syntaxes are now properly rejected. Existing applications that used them will require adjustment. (Bug#34455)
Incompatible Change:
It is no longer possible to create CSV tables
with NULL columns. However, for backwards
compatibility, you can continue to use such tables that were
created in previous MySQL releases.
(Bug#32050)
Incompatible Change:
For packages that are built within their own prefix (for
example, /usr/local/mysql) the plugin
directory will be lib/plugin. For packages
that are built to be installed into a system-wide prefix (such
as RPM packages with a prefix of /usr), the
plugin directory will be lib/mysql/plugin
to ensure a clean /usr/lib hierarchy. In
both cases, the $pkglibdir configuration
setting is used at build time to set the plugin directory.
The current plugin directory location is available as the value
of the plugin_dir system variable as before,
but the mysql_config script now has a
--plugindir option that can be used externally
to the server by third-party plugin writers to obtain the
default plugin directory pathname and configure their
installation directory appropriately.
(Bug#31736)
Incompatible Change:
Inserting a row with a NULL value for a
DATETIME column results in a
CSV file that the storage engine cannot read.
All CSV tables now need to be defined with
each column marked as NOT NULL. An error is
raised if you try to create a CSV table with
columns that are not defined with NOT NULL.
(Bug#31473, Bug#32817)
Incompatible Change:
The utf8_general_ci and
ucs2_general_ci collations did not sort the
letter "U+00DF SHARP S" equal to 's'.
As a result of this fix, any indexes on columns that use these
collations (but only columns that use SHARP S) must be rebuilt
when upgrading to 6.0.5 or higher. To do this, use
ALTER TABLE to drop and re-add
the indexes, or mysqldump to dump the
affected tables and mysql to reload the dump
file.
(Bug#27877)
See also Bug#37046
Incompatible Change:
Several changes were made to the processing of multiple-table
DELETE statements:
Statements could not perform cross-database deletes unless the tables were referred to without using aliases. This limitation has been lifted and table aliases now are allowed.
Previously, alias declarations could be given for tables
elsewhere than in the
table_references part of the
syntax. This could lead to ambiguous statements that have
unexpected results such as deleting rows from the wrong
table. Example:
DELETE FROM t1 AS a2 USING t1 AS a1 INNER JOIN t2 AS a2;
Now alias declarations can be declared only in the
table_references part. Elsewhere
in the statement, alias references are allowed but not alias
declarations.
Alias resolution was improved so that it is no longer possible to have inconsistent or ambiguous aliases for tables.
Statements containing alias constructs that are no longer allowed must be rewritten. (Bug#27525)
See also Bug#30234
Important Change: Replication:
When the master crashed during an update on a transactional
table while in AUTOCOMMIT mode, the slave
failed. This fix causes every transaction (including
AUTOCOMMIT transactions) to be recorded in
the binlog as starting with a
BEGIN and
ending with a COMMIT or
ROLLBACK.
(Bug#26395)
Important Change:
It was possible to use FRAC_SECOND as a
synonym for MICROSECOND with
DATE_ADD(),
DATE_SUB(), and
INTERVAL; now, using
FRAC_SECOND with anything other than
TIMESTAMPADD() or
TIMESTAMPDIFF() produces a syntax
error.
It is now possible (and preferable) to use
MICROSECOND with
TIMESTAMPADD() and
TIMESTAMPDIFF(), and
FRAC_SECOND is now deprecated.
(Bug#33834)
Important Change:
InnoDB free space information is now shown in
the Data_free column of
SHOW TABLE STATUS and in the
DATA_FREE column of the
INFORMATION_SCHEMA.TABLES table.
(Bug#32440)
This regression was introduced by Bug#11379
Important Change:
The server handled truncation of values having excess trailing
spaces into CHAR,
VARCHAR, and
TEXT columns in different ways.
This behavior has now been made consistent for columns of all
three of these types, and now follows the existing behavior of
VARCHAR columns in this regard;
that is, a Note is always issued whenever
such truncation occurs.
This change does not affect columns of these three types when
using a binary encoding; BLOB
columns are also unaffected by the change, since they always use
a binary encoding.
(Bug#30059)
Important Change:
An AFTER UPDATE trigger was not invoked when
the UPDATE did not make any
changes to the table for which the trigger was defined. Now
AFTER UPDATE triggers behave the same in this
regard as do BEFORE UPDATE triggers, which
are invoked whether the UPDATE
makes any changes in the table or not.
(Bug#23771)
Replication: Important Note: Network timeouts between the master and the slave could result in corruption of the relay log. This fix rectifies a long-standing replication issue when using unreliable networks, including replication over wide area networks such as the Internet. If you experience reliability issues and see many You have an error in your SQL syntax errors on replication slaves, we strongly recommend that you upgrade to a MySQL version which includes this fix. (Bug#26489)
MySQL Cluster:
When all data and SQL nodes in the cluster were shut down
abnormally (that is, other than by using STOP
in the cluster management client), ndb_mgm
used excessive amounts of CPU.
(Bug#33237)
MySQL Cluster: There was a short interval during the startup process prior to the beginning of heartbeat detection such that, were an API or management node to reboot or a network failure to occur, data nodes could not detect this, with the result that there could be a lingering connection. (Bug#28445)
Partitioning:
In some cases, matching rows from a partitioned
MyISAM using a
BIT column as the primary key
were not found by queries.
(Bug#34358)
Partitioning:
Enabling innodb_file_per_table produced
problems with partitioning and tablespace operations on
partitioned InnoDB tables, in some cases
leading to corrupt partitions or causing the server to crash.
(Bug#33429)
Partitioning:
A table defined using PARTITION BY KEY and
having a BIT column referenced in
the partitioning key did not behave correctly; some rows could
be inserted into the wrong partition, causing wrong results to
be returned from queries.
(Bug#33379)
Partitioning: It was possible to partition a table to which a foreign key referred. (Bug#32948)
Partitioning:
When ALTER TABLE DROP PARTITION was executed
on a table on which there was a trigger, the statement failed
with an error. This occurred even if the trigger did not
reference any tables.
(Bug#32943)
Partitioning:
A query of the form SELECT
against a
partitioned col1 FROM
table GROUP BY (SELECT
col2 FROM
table LIMIT 1);table having a
SET column crashed the server.
(Bug#32772)
Partitioning:
SHOW CREATE TABLE misreported the
value of AUTO_INCREMENT for partitioned
tables using either of the InnoDB or
ARCHIVE storage engines.
(Bug#32247)
Partitioning:
Selecting from
INFORMATION_SCHEMA.PARTITIONS while
partition management statements (for example, ALTER
TABLE ... ADD PARTITION) were executing caused the
server to crash.
(Bug#32178)
Partitioning:
An error in the internal function
mysql_unpack_partition() led to a fatal
error in subsequent calls to
open_table_from_share().
(Bug#32158)
Partitioning:
Currently, all partitions of a partitioned table must use the
same storage engine. One may optinally specify the storage
engine on a per-partition basis; however, where this is the
done, the storage engine must be the same as used by the table
as a whole. ALTER TABLE did not
enforce these rules correctly, the result being that incaccurate
error messages were shown when trying to use the statement to
change the storage engine used by an individual partition or
partitions.
(Bug#31931)
Partitioning:
ORDER BY ... DESC did not always work
correctly when selecting from partitioned tables.
(Bug#31890)
See also Bug#31001
Partitioning:
ALTER TABLE ... COALESCE PARTITION on a table
partitioned by [LINEAR] HASH or
[LINEAR] KEY caused the server to crash.
(Bug#30822)
Partitioning:
When the range access method was used on a
partitioned Falcon table, the entire index
was scanned. For partitioned tables using other storage engines,
a related issue caused an ordered range scan to return some rows
twice.
(Bug#30573, Bug#33257, Bug#33555)
Partitioning:
LIKE queries on tables partitioned by
KEY could return incomplete results. The
problem was observed with the Falcon storage
engine, but could affect third-party storage engines as well.
(Bug#30480)
Partitioning: Using the DATA DIRECTORY and INDEX DIRECTORY options for partitions with CREATE TABLE or ALTER TABLE statements appeared to work on Windows, although they are not supported by MySQL on Windows systems, and subsequent attempts to use the tables referenced caused errors. Now these options are disabled on Windows, and attempting to use them generates a warning. (Bug#30459)
Partitioning: It was not possible to insert the greatest possible value for a given data type into a partitioned table. For example, consider a table defined as shown here:
CREATE TABLE t (c BIGINT UNSIGNED)
PARTITION BY RANGE(c) (
PARTITION p0 VALUES LESS THAN MAXVALUE
);
The largest possible value for a BIGINT
UNSIGNED column is 18446744073709551615, but the
statement INSERT INTO t VALUES
(18446744073709551615); would fail, even though the
same statement succeeded were t not a
partitioned table.
In other words, MAXVALUE was treated as being
equal to the greatest possible value, rather than as a least
upper bound.
(Bug#29258)
Replication:
Replicating a Falcon table that contained a
TEXT or
BLOB column would fail during a
DELETE operation with the error
HA_ERR_END_OF_FILE.
(Bug#36468)
Replication:
When using row-based replication, a slave could crash at startup
because it received a row-based replication event that
InnoDB could not handle due to an incorrect
test of the query string provided by MySQL, which was
NULL for row-based replication events.
(Bug#35226)
Replication:
INSERT_ID was not written to the binary log
for inserts into BLACKHOLE tables.
(Bug#35178)
Replication:
When using statement-based replication and a
DELETE,
UPDATE, or INSERT ...
SELECT statement using a LIMIT
clause is encountered, a warning that the statement is not safe
to replicate in statement mode is now issued; when using
MIXED mode, the statement is now replicated
using the row-based format.
(Bug#34768)
Replication:
mysqlbinlog did not output the values of
auto_increment_increment and
auto_increment_offset when both were equal to
their default values (for both of these variables, the default
is 1). This meant that a binary log recorded by a client using
the defaults for both variables and then replayed on another
client using its own values for either or both of these
variables produced erroneous results.
(Bug#34732)
See also Bug#31168
Replication:
A CHANGE MASTER TO statement with
no MASTER_HEARTBEAT_PERIOD option failed to
reset the heartbeat period to its default value.
(Bug#34686)
Replication:
SHOW SLAVE STATUS failed when
slave I/O was about to terminate.
(Bug#34305)
Replication: The character sets and collations used for constant identifiers in stored procedures were not replicated correctly. (Bug#34289)
Replication:
mysqlbinlog from a 5.1 or later MySQL
distribution could not read binary logs generated by a 4.1
server when the logs contained
LOAD DATA
INFILE statements.
(Bug#34141)
This regression was introduced by Bug#32407
Replication:
A CREATE USER,
DROP USER, or
RENAME USER statement that fails
on the master, or that is a duplicate of any of these
statements, is no longer written to the binlog; previously,
either of these occurrences could cause the slave to fail.
See also Bug#29749
Replication:
SHOW BINLOG EVENTS could fail
when the binlog contained one or more events whose size was
close to the value of max_allowed_packet.
(Bug#33413)
Replication: mysqlbinlog failed to release all of its memory after terminating abnormally. (Bug#33247)
Replication:
When a stored routine or trigger, running on a master that used
MySQL 5.0 or MySQL 5.1.11 or earlier, performed an insert on an
AUTO_INCREMENT column, the
INSERT_ID value was not replicated correctly
to a slave running MySQL 5.1.12 or later (including any MySQL
6.0 release).
(Bug#33029)
See also Bug#19630
Replication: The error message generated due to lack of a default value for an extra column was not sufficiently informative. (Bug#32971)
Replication:
When a user variable was used inside an
INSERT statement, the
corresponding binlog event was not written to the binlog
correctly.
(Bug#32580)
Replication: When using row-based replication, deletes from a table with a foreign key constraint failed on the slave. (Bug#32468)
Replication:
The --base64-output option for
mysqlbinlog was not honored for all types of
events. This interfered in some cases with performing
point-in-time recovery.
(Bug#32407)
Replication:
SQL statements containing comments using --
syntax were not replayable by mysqlbinlog,
even though such statements replicated correctly.
(Bug#32205)
Replication: When using row-based replication from a master running MySQL 6.0.3 or earlier to a slave running 6.0.4 or later, updates of integer columns failed on the slave with Error in Unknown event: row application failed. (Bug#31583)
This regression was introduced by Bug#21842
Replication: Replicating write, update, or delete events from a master running MySQL 5.1.15 or earlier to a slave running 5.1.16 or later caused the slave to crash. (Bug#31581)
Replication: When using row-based replication, the slave stopped when attempting to delete non-existent rows from a slave table without a primary key. In addition, no error was reported when this occurred. (Bug#31552)
Replication:
Errors due to server ID conflicts were reported only in the
slave's error log; now these errors are also shown in the
Server_IO_State column in the output of
SHOW SLAVE STATUS.
(Bug#31316)
Replication:
STOP SLAVE did not stop
connection attempts properly. If the IO slave thread was
attempting to connect, STOP SLAVE
waited for the attempt to finish, sometimes for a long period of
time, rather than stopping the slave immediately.
(Bug#31024)
See also Bug#30932
Replication:
Issuing a DROP VIEW statement
caused replication to fail if the view did not actually exist.
(Bug#30998)
Replication:
Replication of LOAD
DATA INFILE could fail when
read_buffer_size was larger than
max_allowed_packet.
(Bug#30435)
Replication:
Replication crashed with the NDB storage
engine when mysqld was started with
--character-set-server=ucs2.
(Bug#29562)
Replication: The effects of scheduled events were not always correctly reproduced on the slave when using row-based replication. (Bug#29020)
Replication:
Setting server_id did not update its value
for the current session.
(Bug#28908)
Replication: Some older servers wrote events to the binary log using different numbering from what is currently used, even though the file format number in the file is the same. Slaves running MySQL 5.1.18 and later could not read these binary logs properly. Binary logs from these older versions now are recognized and event numbers are mapped to the current numbering so that they can be interpreted properly. (Bug#27779, Bug#32434)
This regression was introduced by Bug#22583
Replication:
MASTER_POS_WAIT() did not return
NULL when the server was not a slave.
(Bug#26622)
Replication:
The inspecific error message Wrong parameters to
function register_slave resulted when
START SLAVE failed to register on
the master due to excess length of any the slave server options
--report-host, --report-user,
or --report-password. An error message specific
to each of these options is now returned in such cases. The new
error messages are:
Failed to register slave: too long 'report-host'
Failed to register slave: too long 'report-user'
Failed to register slave; too long 'report-password'
See also Bug#19328
Replication:
PURGE BINARY LOGS TO and PURGE
BINARY LOGS BEFORE did not handle missing binary log
files correctly or in the same way. Now for both of these
statements, if any files listed in the
.index file are missing from the
filesystem, the statement fails with an error.
API:
When the language option was not set correctly, API programs
calling mysql_server_init()
crashed. This issue was observed only on Windows platforms.
(Bug#31868)
Corrected a typecast involving bool on Mac OS
X 10.5 (Leopard), which evaluated differently from earlier Mac
OS X versions.
(Bug#38217)
BACKUP DATABASE did not correctly
determine dependency ordering of backed-up objects, which could
cause a RESTORE operation to
fail.
(Bug#36531)
Concurrent LOAD DATA
INFILE statements inserting data into
Falcon tables could crash the server.
(Bug#35982)
Following a server crash, recovery of Falcon
tables containing BLOB or
TEXT columns could lose data.
(Bug#35688)
Manually replacing a binary log file with a directory having the same name caused an error that was not handled correctly. (Bug#35675)
Using LOAD DATA
INFILE with a view could crash the server.
(Bug#35469)
Selecting from
INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
could cause a server crash.
(Bug#35406)
See also Bug#35108
For a TEMPORARY table,
DELETE with no
WHERE clause could fail when preceded by
DELETE statements with a
WHERE clause.
(Bug#35392)
In some cases, when too many clients tried to connect to the
server, the proper SQLSTATE code was not
returned.
(Bug#35289)
Memory-allocation failures for attempts to set
key_buffer_size to large values could result
in a server crash.
(Bug#35272)
Queries could return different results depending on whether
ORDER BY columns were indexed.
(Bug#35206)
When a view containing a reference to DUAL
was created, the reference was removed when the definition was
stored, causing some queries against the view to fail with
invalid SQL syntax errors.
(Bug#35193)
SELECT ... FROM
INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS caused the
server to crash if the table referenced by a foreign key had
been dropped. This issue was observed on Windows platforms only.
(Bug#35108)
See also Bug#35406
Debugging symbols were missing for some executables in Windows binary distributions. (Bug#35104)
Non-connection threads were being counted in the value of the
Max_used_connections status variable.
(Bug#35074)
Two different threads could obtain the same record number for
concurrent inserts into the same Falcon
table.
(Bug#34990)
A query that performed a ref_or_null join
where the second table used a key having one or columns that
could be NULL and had a column value that was
NULL caused the server to crash.
(Bug#34945)
This regression was introduced by Bug#12144
For some queries, the optimizer used an ordered index scan for
GROUP BY or DISTINCT when
it was supposed to use a loose index scan, leading to incorrect
results.
(Bug#34928)
Creating a foreign key on an InnoDB table
that was created with an explicit
AUTO_INCREMENT value caused that value to be
reset to 1.
(Bug#34920)
mysqldump failed to return an error code when
using the --master-data option without binary
logging being enabled on the server.
(Bug#34909)
Under some circumstances, the value of
mysql_insert_id() following a
SELECT ... INSERT statement could return an
incorrect value. This could happen when the last SELECT
... INSERT did not involve an
AUTO_INCREMENT column, but the value of
mysql_insert_id() was changed by
some previous statements.
(Bug#34889)
Logging to the progress tables used by
BACKUP DATABASE and
RESTORE caused a server crash.
(Bug#34858)
Table and database names were mixed up in some places of the subquery transformation procedure. This could affect debugging trace output and further extensions of that procedure. (Bug#34830)
If fsync() returned
ENOLCK, InnoDB could treat
this as fatal and cause abnormal server termination.
InnoDB now retries the operation.
(Bug#34823)
CREATE SERVER and
ALTER SERVER could crash the
server if out-of-memory conditions occurred.
(Bug#34790)
DROP SERVER does not release
memory cached for server structures created by
CREATE SERVER, so repeated
iterations of these statements resulted in a memory leak.
FLUSH
PRIVILEGES now releases the memory allocated for
CREATE SERVER.
(Bug#34789)
A malformed URL used for a FEDERATED
table's CONNECTION option value in a
CREATE TABLE statement was not
handled correctly and could crash the server.
(Bug#34788)
Repeated UPDATE operations on a
Falcon table could cause a memory leak.
(Bug#34778)
Queries such as SELECT ROW(1, 2) IN (SELECT t1.a, 2)
FROM t1 GROUP BY t1.a (combining row constructors and
subqueries in the FROM clause) could lead to
assertion failure or unexpected error messages.
(Bug#34763)
Using NAME_CONST() with a negative number and
an aggregate function caused MySQL to crash. This could also
have a negative impact on replication.
(Bug#34749)
A memory-handling error associated with use of
GROUP_CONCAT() in subqueries
could result in a server crash.
(Bug#34747)
For an indexed integer column
col_name and a value
N that is one greater than the
maximum value allowed for the data type of
col_name, conditions of the form
WHERE failed to return rows
where the value of col_name <
Ncol_name is
.
(Bug#34731)N - 1
A server running with the --debug option could
attempt to dereference a null pointer when opening tables,
resulting in a crash.
(Bug#34726)
Assigning an “incremental” value to the
debug system variable did not add the new
value to the current value. For example, if the current
debug value was 'T', the
statement SET debug = '+P' resulted in a
value of 'P' rather than the correct value of
'P:T'.
(Bug#34678)
For debug builds, reading from
INFORMATION_SCHEMA.TABLES or
INFORMATION_SCHEMA.COLUMNS could
cause assertion failures. This could happen under rare
circumstances when INFORMATION_SCHEMA fails
to get information about a table (for example, when a connection
is killed).
(Bug#34656)
Executing a TRUNCATE statement on
a table having both a foreign key reference and a
DELETE trigger crashed the
server.
(Bug#34643)
Some subqueries using an expression that included an aggregate function could fail or in some cases lead to a crash of the server. (Bug#34620)
Dangerous pointer arithmetic crashed the server on some systems. (Bug#34598)
Creating a view inside a stored procedure could lead to a crash of the MySQL Server. (Bug#34587)
Concurrent ALTER TABLE operations
on temporary and non-temporary Falcon tables
caused the server to hang.
(Bug#34567)
This regression was introduced by Bug#33634
A server crash could occur if
INFORMATION_SCHEMA tables built in memory
were swapped out to disk during query execution.
(Bug#34529)
CAST(AVG( produced incorrect results for
non-arg) AS
DECIMAL)DECIMAL arguments.
(Bug#34512)
SET GLOBAL falcon_record_chill_threshold and
SET GLOBAL falcon_index_chill_threshold did
not work.
(Bug#34486)
The per-thread debugging settings stack was not being deallocated before thread termination, resulting in a stack memory leak. (Bug#34424)
Client applications could not connect to the server on Windows Vista because the server was creating an IPv6-only TCP/IP socket. (Bug#34381)
Inserting a unique record into a Falcon
table, then performing a DELETE
on the same record resulted in the error Record has
changed since last read.
(Bug#34351)
Executing an ALTER VIEW statement
on a table crashed the server.
(Bug#34337)
For InnoDB, exporting and importing a table
could corrupt TINYBLOB columns,
and a subsequent ALTER TABLE
could corrupt TINYTEXT columns as
well.
(Bug#34300)
On Windows, client programs generated assertion failures. (Bug#34298)
DEFAULT 0 was not allowed for the
YEAR data type.
(Bug#34274)
Under some conditions, a SET GLOBAL
innodb_commit_concurrency or SET GLOBAL
innodb_autoextend_increment statement could fail.
(Bug#34223)
mysqldump attempts to set the
character_set_results system variable after
connecting to the server. This failed for pre-4.1 servers that
have no such variable, but mysqldump did not
account for this and 1) failed to dump database contents; 2)
failed to produce any error message alerting the user to the
problem.
(Bug#34192)
Use of stored functions in the WHERE clause
for SHOW OPEN TABLES caused a
server crash.
(Bug#34166)
Compilation failed on Solaris for the ARCHIVE
storage engine due to inclusion of getopt.h
in the ARCHIVE code.
(Bug#34094)
CREATE TABLE ... ENGINE=Falcon failed with an
unhelpful error message when the Falcon
storage engine had failed to allocate the page cache properly on
server startup. Now, Falcon is initialized on
server startup, and is not loaded if the allocation fails.
(Bug#34085)
Updates of floating-point columns in
FEDERATED tables could produce incorrect
results.
(Bug#34015)
For a FEDERATED table with an index on a
nullable column, accessing the table could crash a server,
return an incorrect result set, or return ERROR 1030
(HY000): Got error 1430 from storage engine.
(Bug#33946)
Passing anything other than a integer to a
LIMIT clause in a prepared statement would
fail. (This limitation was introduced to avoid replication
problems; for example, replicating the statement with a string
argument would cause a parse failure in the slave). Now,
arguments to the LIMIT clause are converted
to integer values, and these converted values are used when
logging the statement.
(Bug#33851)
An internal buffer in mysql was too short. Overextending it could cause stack problems or segmentation violations on some architectures. (This is not a problem that could be exploited to run arbitrary code.) (Bug#33841)
A query using WHERE
(column1=', where
string1' AND
column2=constant1) OR
(column1='string2' AND
column2=constant2)col1 used a binary collation and
string1 matched
string2 except for case, failed to
match any records even when matches were found by a query using
the equivalent clause WHERE
column2=.
(Bug#33833)constant1 OR
column2=constant2
Large unsigned integers were improperly handled for prepared statements, resulting in truncation or conversion to negative numbers. (Bug#33798)
Reuse of prepared statements could cause a memory leak in the embedded server. (Bug#33796)
The server crashed when executing a query that had a subquery
containing an equality X=Y where Y referred to a named select
list expression from the parent select. The server crashed when
trying to use the X=Y equality for ref-based
access.
(Bug#33794)
Some queries using a combination of IN,
CONCAT(), and an implicit type
conversion could return an incorrect result.
(Bug#33764)
In some cases a query that produced a result set when using
ORDER BY ASC did not return any results when
this was changed to ORDER BY DESC.
(Bug#33758)
Disabling concurrent inserts caused some cacheable queries not to be saved in the query cache. (Bug#33756)
The UPDATE statement allowed NULL to be
assigned to NOT NULL columns (the default
data type value was assigned). An error occurs now.
(Bug#33699)
ORDER BY ... DESC sorts could produce
misordered results.
(Bug#33697)
Use of uninitialized memory for filesort in a
subquery caused a server crash.
(Bug#33675)
The WEIGHT_STRING() function
returned incorrect results for column values when earlier column
values were NULL.
(Bug#33663)
The server could crash when REPEAT or another
control instruction was used in conjunction with labels and a
LEAVE instruction.
(Bug#33618)
The parser allowed control structures in compound statements to have mismatched beginning and ending labels. (Bug#33618)
make_binary_distribution passed the
--print-libgcc-file option to the C compiler,
but this does not work with the ICC compiler.
(Bug#33536)
Threads created by the event scheduler were incorrectly counted
against the max_connections thread limit,
which could lead to client lockout.
(Bug#33507)
CREATE TABLE ... ENGINE=Falcon failed on
kernel 2.4 based Linux systems when using
O_DIRECT with an NFS filesystem.
(Bug#33484)
Dropping a function after dropping the function's creator could cause the server to crash. (Bug#33464)
For the latin2_czech_cs collation, the
primary weights for all variants of capital letters
U and O were incorrect
(were not equal to the corresponding small letters).
(Bug#33452)
Certain combinations of views, subselects with outer references and stored routines or triggers could cause the server to crash. (Bug#33389)
SET GLOBAL myisam_max_sort_file_size=DEFAULT
set myisam_max_sort_file_size to an incorrect
value.
(Bug#33382)
See also Bug#31177
ENUM- or
SET-valued plugin variables could not be set
from the command line.
(Bug#33358)
If the mysql database was named in the
BACKUP DATABASE statement, the
backup operation hung.
(Bug#33355)
Loading plugins via command-line options to mysqld could cause an assertion failure. (Bug#33345)
SLEEP(0) failed to return on
64-bit Mac OS X due to a bug in
pthread_cond_timedwait().
(Bug#33304)
CREATE TABLE ... SELECT created tables that
for date columns used the obsolete Field_date
type instead of Field_newdate.
(Bug#33256)
For MyISAM tables, CHECK
TABLE (non-QUICK) and any form of
REPAIR TABLE incorrected treated
rows as corrupted under the combination of the following
conditions:
The table had dynamic row format
The table had a CHAR (not
VARCHAR) column longer than
127 bytes (for multi-byte character sets this could be less
than 127 characters)
The table had rows with a signifcant length of more than 127
bytes significant length in that
CHAR column (that is, a byte
beyond byte position 127 must be a non-space character)
This problem affected CHECK
TABLE, REPAIR TABLE,
OPTIMIZE TABLE,
ALTER TABLE.
CHECK TABLE reported and marked
the table as crashed if any row was present that fulfilled the
third condition. The other statements deleted these rows.
(Bug#33222)
The error message was vague for attempts to drop a
Falcon tablespace that contained tables. Now
the message Tablespace busy is returned.
(Bug#33216)
When creating temporary tables within Falcon,
the tables are automatically created in the
FALCON_TEMPORARY tablespace. If you specify
an alternate tablespace to the CREATE
TABLE statement a warning will now be issued to that
effect.
(Bug#33211)
Granting the UPDATE privilege on
one column of a view caused the server to crash.
(Bug#33201)
For DECIMAL columns used with the
ROUND(
or
X,D)TRUNCATE(
function with a non-constant value of
X,D)D, adding an ORDER
BY for the function result produced misordered output.
(Bug#33143)
Some valid SELECT statements
could not be used as views due to incorrect column reference
resolution.
(Bug#33133)
The weight for supplementary Unicode characters should be
0xFFFD, but the
WEIGHT_STRING() function returned
0x0DC6 instead.
(Bug#33077)
The CSV engine did not honor update requests
for BLOB columns when the new
column value had the same length as the value to be updated.
(Bug#33067)
After receiving a SIGHUP signal, the server
could crash, and user-specified log options were ignored when
reopening the logs.
(Bug#33065)
Repeatedly executing a query with a semi-join subquery could cause a server crash. (Bug#33062)
The fix for Bug#11230 and Bug#26215 introduced a significant input-parsing slowdown for the mysql client. This has been corrected. (Bug#33057)
When MySQL was built with OpenSSL, the SSL library was not properly initialized with information of which endpoint it was (server or client), causing connection failures. (Bug#33050)
Under some circumstances a combination of aggregate functions
and GROUP BY in a
SELECT query over a view could
lead to incorrect calculation of the result type of the
aggregate function. This in turn could lead to incorrect
results, or to crashes on debug builds of the server.
(Bug#33049)
It was not possible to set the value of
falcon_consistent_read within the local
scope. You can now set the global value, using
SET
GLOBAL, but this affects only the current local scope
and all new connections made after the global variable was set.
(Bug#33041)
The new index condition pushdown optimization could cause a
server crash when used with the range access method over an
InnoDB table.
(Bug#33033)
For DISTINCT queries, 4.0 and 4.1 stopped
reading joined tables as soon as the first matching row was
found. However, this optimization was lost in MySQL 5.0, which
instead read all matching rows. This fix for this regression may
result in a major improvement in performance for
DISTINCT queries in cases where many rows
match.
(Bug#32942)
Repeated creation and deletion of views within prepared statements could eventually crash the server. (Bug#32890)
See also Bug#34587
The correct data type for a NULL column
resulting from a UNION could be determined
incorrectly in some cases: 1) Not correctly inferred as
NULL depending on the number of selects; 2)
Not inferred correctly as NULL if one select
used a subquery.
(Bug#32848)
For queries containing GROUP_CONCAT(DISTINCT
, there was a
limitation that the col_list ORDER BY
col_list)DISTINCT columns had to
be the same as ORDER BY columns. Incorrect
results could be returned if this was not true.
(Bug#32798)
Incorrect assertions could cause a server crash for
DELETE triggers for transactional
tables.
(Bug#32790)
SHOW EVENTS and selecting from
the INFORMATION_SCHEMA.EVENTS table
failed if the current database was
INFORMATION_SCHEMA.
(Bug#32775)
In some cases where setting a system variable failed, no error was sent to the client, causing the client to hang. (Bug#32757)
Enabling the PAD_CHAR_TO_FULL_LENGTH SQL mode
caused privilege-loading operations (such as
FLUSH
PRIVILEGES) to include trailing spaces from grant
table values stored in CHAR
columns. Authentication for incoming connections failed as a
result. Now privilege loading does not include trailing spaces,
regardless of SQL mode.
(Bug#32753)
Use of the cp932 character set with
CAST() in an ORDER
BY clause could cause a server crash.
(Bug#32726)
The SHOW ENGINE
INNODB STATUS and
SHOW ENGINE INNODB
MUTEX statements incorrectly required the
SUPER privilege rather than the
PROCESS privilege.
(Bug#32710)
Inserting strings with a common prefix into a table that used
the ucs2 character set corrupted the table.
(Bug#32705)
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 non-existent column for an INSERT
DELAYED statement caused a server crash rather than
producing an error.
(Bug#32676)
Tables in the mysql database that stored the
current sql_mode value as part of stored
program definitions were not updated with newer mode values
(NO_ENGINE_SUBSTITUTION,
PAD_CHAR_TO_FULL_LENGTH). This causes various
problems defining stored programs if those modes were included
in the current sql_mode value.
(Bug#32633)
Use of CLIENT_MULTI_QUERIES caused
libmysqld to crash.
(Bug#32624)
A SELECT ... GROUP BY
query failed
with an assertion if the length of the
bit_columnBIT column used for the
GROUP BY was not an integer multiple of 8.
(Bug#32556)
A view created with a string literal for one of the columns picked up the connection character set, but not the collation. Comparison to that field therefore used the default collation for that character set, causing an error if the connection collation was not compatible with the default collation. The problem was caused by text literals in a view being dumped with a character set introducer even when this was not necessary, sometimes leading to a loss of collation information. Now the character set introducer is dumped only if it was included in the original query. (Bug#32538)
See also Bug#21505
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)
Queries using LIKE on tables having indexed
CHAR columns using either of the
eucjpms or ujis character
sets did not return correct results.
(Bug#32510)
A query of the form SELECT
@ crashed
the server.
(Bug#32482)user_variable :=
constant AS
alias FROM
table GROUP BY
alias WITH ROLLUP
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)
If a global read lock acquired with
FLUSH TABLES WITH READ
LOCK was in effect, executing
ALTER TABLE could cause a server
crash.
(Bug#32395)
utf16 columns allowed incorrect Unicode
characters inserted through conversion from another Unicode
character set.
(Bug#32393)
An ORDER BY query on a view created using a
FEDERATED table as a base table caused the
server to crash.
(Bug#32374)
The mysqldump utility did not print enough
version information about itself at the top of its output. The
output now shows the same information as
mysqldump invoked with the
-V option, namely the
mysqldump version number, the MySQL server
version, and the distribution.
(Bug#32350)
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)
Executing a prepared statement associated with a materialized cursor sent to the client a metadata packet with incorrect table and database names. The problem occurred because the server sent the name of the temporary table used by the cursor instead of the table name of the original table.
The same problem occured when selecting from a view, in which case the name of the table name was sent, rather than the name of the view. (Bug#32265)
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)
The default grant tables on Windows contained information for
host production.mysql.com, which should not
be there.
(Bug#32219)
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)
When configure was run with
--with-libevent, libevent
was not linked statically with mysqld,
preventing mysqld from being run with a
debugger.
(Bug#32156)
InnoDB adaptive hash latches could be held
too long, resulting in a server crash. This fix may also provide
significant performance improvements on systems on which many
queries using filesorts with temporary tables are being
performed.
(Bug#3214

