ius-coredev team mailing list archive
-
ius-coredev team
-
Mailing list archive
-
Message #03460
[Bug 1117674] Re: WL: mysql56
Hello,
Earlier this week, I have been working on mysql56u-5.6.15 packages and
they will be hitting the development repos tonight. I described the
earlier packages as 'quick an dirty', while I would describe the
mysql56u-5.6.15 packages as 'getting refined'. I will be soliciting
from our trusted DBAs and anyone else that is interested in testing
these new packages.
-Ben
--
You received this bug notification because you are a member of IUS Core
Development, which is subscribed to IUS Community Project.
https://bugs.launchpad.net/bugs/1117674
Title:
WL: mysql56
Status in IUS Community Project:
New
Bug description:
Dear MySQL users,
MySQL Server 5.6.10 (GA) is a new version of the world's most popular
open source database. This is the first official release of MySQL 5.6.
The new features in this release are now deemed to be of Release
quality.
Note that 5.6.10 includes all features in MySQL 5.5 and previous 5.6
Development Milestone Releases. An overview of what's new in MySQL 5.6
is available online at
http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html
For information on installing MySQL 5.6.10 on new servers, please see the
MySQL installation documentation at
http://dev.mysql.com/doc/refman/5.6/en/installing.html
For upgrading from previous MySQL releases, please see the important
upgrade considerations at
http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-
series.html
MySQL Server 5.6.10 is available in source and binary form for a number
of platforms from our download pages at
http://dev.mysql.com/downloads/mysql/
Please note that the list of platforms for MySQL 5.6 has been adapted to
the changes in the field:
- Apple Mac OS X 10.6 and 10.7 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for OS X 10.5),
- Debian 6 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for Debian 5),
- RedHat Enterprise / Oracle Linux 5 and 6 on x86 (32 bit) and x86_64
(Binary packages of MySQL 5.6 are not provided for RHEL/OL 4),
- SuSE Enterprise Linux 11 on x86_64
(Binary packages of MySQL 5.6 are not provided for SLES 10),
- generic Linux (kernel 2.6) on x86 (32 bit) and x86_64,
using glibc 2.5 (or newer),
- FreeBSD 9 on x86_64
(Binary packages of MySQL 5.6 are not provided for FreeBSD 7 and 8),
- Oracle Solaris 10 and 11 on Sparc (64 bit), x86 (32 bit) and x86_64,
- Windows Vista, 7, 8, Server 2008 on x86 (32 bit) and x86_64,
Server 2008 R2 and Server 2012 on x86_64 only.
(Binary packages of MySQL 5.6 are not provided for Windows XP and
2003).
This does not affect the list of supported platforms for 5.1 and 5.5.
For Linux, the dependency on glibc 2.5 is new with 5.6, it is
reflected in the names of the binary packages for generic Linux:
"linux-glibc2.5" (former: "linux2.6").
All supported specific platforms (RedHat 5 and newer, SuSE 11, ...) are
using glibc 2.5 or newer.
If you want to check your system, you may simply "run" the library:
| Prompt$ /lib/libc.so.6
| GNU C Library stable release version 2.7, by Roland McGrath et al.
| Copyright (C) 2007 Free Software Foundation, Inc.
| ...
The above example was done on Debian 6, it shows glibc 2.7.
Packages for specific Linux distributions are provided in the specific
format (RPM or deb), in addition the generic tar.gz packages will fit
these distributions.
For RedHat-alike distributions like CentOS or Fedora, both the RedHat
and the generic packages should work.
If you are using a newer version of your operating system, its binary
compatibility approach (supporting applications built for older
versions) should ensure you can use MySQL 5.6.
Windows packages are now available via the new Installer for Windows
Installer or .ZIP (no-install) packages for more advanced needs. It
should be noted that the previous MSI packaging is no longer available
and the point and click configuration wizards and all MySQL products
are now available in the unified Installer for Windows:
http://dev.mysql.com/downloads/installer/
The list of all "Bugs Fixed" for 5.6.10 may also be viewed online at
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-10.html
If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration and migration tools so
businesses can achieve the highest levels of MySQL performance,
security and uptime.
http://mysql.com/products/enterprise/
More information is available here:
http://dev.mysql.com/doc/refman/5.6/en/mysql-enterprise.html
On behalf of the MySQL release Engineering Team,
- Bjorn Munch
Enjoy!
-----------------------------------------
Changes in MySQL 5.6.10 (5 February 2013)
Beginning with MySQL 5.6.10, MySQL Enterprise Edition is available
for MySQL 5.6. Specifically, MySQL Enterprise 5.6.10 includes
these components previously available only in MySQL 5.5: MySQL
Enterprise Security (PAM and Windows authentication plugins),
MySQL Enterprise Audit, and MySQL Thread Pool. For information
about these features, see MySQL Enterprise Edition
( http://dev.mysql.com/doc/refman/5.6/en/mysql-enterprise.html ).
To learn more about commercial products, see
http://www.mysql.com/products/ .
Known limitations of this release:
On Microsoft Windows, when using the MySQL Installer to install
MySQL Server 5.6.10 on a host with an existing MySQL Server of a
different version (such as 5.5.30), that also has a different
license (community versus commercial), you must first update the
license type of the existing MySQL Server. Otherwise, MySQL
Installer will remove MySQL Server(s) with different licenses from
the one you chose with MySQL Server 5.6.10.
On Microsoft Windows 8, updating a community release to a
commercial release requires you to manually restart the MySQL
service after the update.
Functionality Added or Changed
* Replication: An Auto_Position column has been added to the
output generated by SHOW SLAVE STATUS. The value of this
column shows whether replication autopositioning is in use. If
autopositioning is enabled---that is, if MASTER_AUTO_POSITION
= 1 was set by the last successful CHANGE MASTER TO statement
that was executed on the slave---then the column's value is 1;
if not, then the value is 0. (Bug #15992220)
* In RPM packages built for Unbreakable Linux Network,
libmysqld.so now has a version number. (Bug #15972480)
* Error messages for ALTER TABLE statement using a LOCK or
ALGORITHM value not supported for the given operation were
very generic. The server now produces more informative
messages. (Bug #15902911)
* If a client with an expired password connected but
old_passwords was not the value required to select the
password hashing format appropriate for the client account,
there was no way for the client to determine the proper value.
Now the server automatically sets the session old_passwords
value appropriately for the account password. (Bug #15892194)
* The validate_password_policy_number system variable was
renamed to validate_password_policy. (Bug #14588121)
* In JSON-format EXPLAIN output, the attached_condition
information for subqueries now includes select# to indicate
the relative order of subquery execution. (Bug #13897507)
Bugs Fixed
* InnoDB; Performance: Optimized read operations for compressed
(http://dev.mysql.com/doc/refman/5.6/en/glos_compression.html)
tables by skipping redundant tests. The check for whether any
related changes needed to be merged from the insert buffer
(http://dev.mysql.com/doc/refman/5.6/en/glos_insert_buffer.htm
l) was being called more often than necessary. (Bug #14329288,
Bug #65886)
* InnoDB; Performance: Immediately after a table was created,
queries against it would not use loose index scans
(http://dev.mysql.com/doc/refman/5.6/en/loose-index-scan.html)
. The issue went away following an ALTER TABLE on the table.
The fix improves the accuracy of the index statistics
(http://dev.mysql.com/doc/refman/5.6/en/glos_index_statistics.
html) gathered when the table is first created. (Bug
#14200010)
* Replication; Important Change: The lettercasing used for
displaying UUIDs in global transaction identifiers was
inconsistent. Now, all GTID values use lowercase, including
those shown in the Retrieved_Gtid_Set and Executed_Gtid_Set
columns from the output of SHOW SLAVE STATUS. (Bug #15869441)
* InnoDB: Under certain circumstances, an InnoDB table was
reported as corrupted after import using ALTER TABLE ...
IMPORT TABLESPACE. The problem was accompanied by one of these
messages:
Warning : InnoDB: The B-tree of index "PRIMARY" is corrupted.
error : Corrupt
or:
Warning : InnoDB: The B-tree of index "GEN_CLUST_INDEX" is corrupted
.
error : Corrupt
This issue occurred intermittently, and primarily affected
large tables. The REPAIR TABLE statement would fix the problem
reported by the error message. (Bug #15960850, Bug #67807)
* InnoDB: Some Valgrind warnings were issued during shutdown,
while cleaning up a background thread that handles
optimization of tables containing FULLTEXT indexes. (Bug
#15994393)
* InnoDB: If an online DDL operation to add a unique index
failed, because duplicate items were created by concurrent DML
during the online DDL operation, the ALTER TABLE operation
failed with the wrong error type. It returned
ER_INDEX_CORRUPT; now it returns the new error code
ER_DUP_UNKNOWN_IN_INDEX. (It does not return ER_DUP_KEY,
because the duplicate key value is not available to be
reported when this condition occurs.) (Bug #15920713)
* InnoDB: ALTER TABLE statements using the online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
feature could cause Valgrind warnings. (Bug #15933178)
* InnoDB: Names of indexes being created by an online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
operation were being displayed incorrectly in
information_schema tables while the operation was in progress.
This fix ensures the table names have the leading 0xff byte
stripped off for information_schema queries. This change
affects the columns:
+ innodb_buffer_page.index_name
+ innodb_buffer_page_lru.index_name
+ innodb_cmp_per_index.index_name
+ innodb_cmp_per_index_reset.index_name
+ innodb_locks.lock_index
+ innodb_sys_indexes.name
(Bug #15946256)
* InnoDB: The status variable
Innodb_buffer_pool_read_ahead_evicted could show an inaccurate
value, higher than expected, because some pages in the buffer
pool
(http://dev.mysql.com/doc/refman/5.6/en/glos_buffer_pool.html)
were incorrectly considered as being brought in by read-ahead
(http://dev.mysql.com/doc/refman/5.6/en/glos_read_ahead.html)
requests. (Bug #15859402, Bug #67476)
* InnoDB: Creating an index on a CHAR column could fail for a
table with a character set with varying length, such as UTF-8,
if the table was created with the ROW_FORMAT=REDUNDANT clause.
(Bug #15874001)
* InnoDB: If the server crashed near the end of an online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
ALTER TABLE statement, a subsequent CHECK TABLE statement
using the EXTENDED clause could cause a serious error. (Bug
#15878013)
* InnoDB: Specifying an innodb_log_file_size value of 4GB or
larger was not possible on 64-bit Windows systems. This issue
only affected debug builds. (Bug #15882860)
* InnoDB: This fix ensures that in case of a serious unhandled
error during an ALTER TABLE operation that copies the original
table, any data that could be needed for data recovery is
preserved, in tables using names of the form #sql-ib-table_id
or #mysql50##sql-ib-table_id. (Bug #15866623)
* InnoDB: An online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
operation to add a primary key
(http://dev.mysql.com/doc/refman/5.6/en/glos_primary_key.html)
to a table could encounter a serious error if the table also
had an index on a column prefix
(http://dev.mysql.com/doc/refman/5.6/en/glos_column_prefix.htm
l) of a BLOB column.
This fix suspends the background purge
(http://dev.mysql.com/doc/refman/5.6/en/glos_purge.html)
operation while a table is being rebuilt by an ALTER TABLE
statement, if any rows containing off-page columns
(http://dev.mysql.com/doc/refman/5.6/en/glos_off_page_column.h
tml) would be removed. Currently, to avoid excessive space
usage during the online DDL operation, avoid these types of
concurrent DML
(http://dev.mysql.com/doc/refman/5.6/en/glos_dml.html)
operations until the ALTER TABLE is finished:
+ DELETE of rows that contain off-page columns.
+ UPDATE of primary key columns in rows that contain
off-page columns.
+ UPDATE of off-page columns.
(Bug #14827736)
* InnoDB: The server could halt with an assertion error while
creating an index:
InnoDB: Assertion failure in thread thread_num in file row0merge.cc l
ine 465
This issue affected tables with a combination of
ROW_FORMAT=REDUNDANT off-page columns
(http://dev.mysql.com/doc/refman/5.6/en/glos_off_page_column.h
tml), and an index on a column prefix
(http://dev.mysql.com/doc/refman/5.6/en/glos_column_prefix.htm
l). (Bug #14753402)
* InnoDB: information_schema tables with InnoDB metadata, such
as innodb_sys_tablestats, displayed non-alphanumeric
characters in the names of tables using an encoded format, for
example with @0024 instead of $. (Bug #14550145)
* InnoDB: With a large value for innodb_buffer_pool_size, and
innodb_buffer_pool_instances set greater than 1, pages
(http://dev.mysql.com/doc/refman/5.6/en/glos_page.html) were
being incorrectly evicted
(http://dev.mysql.com/doc/refman/5.6/en/glos_eviction.html)
from the buffer pool
(http://dev.mysql.com/doc/refman/5.6/en/glos_buffer_pool.html)
. (Bug #14125092)
* Partitioning: Partition pruning is now enabled for tables
using a storage engine that provides automatic partitioning,
such as the NDB storage engine, but which are explicitly
partitioned. Previously, pruning was disabled for all tables
using such a storage engine, whether or not the tables had
explicitly defined partitions.
In addition, as part of this fix, explicit partition selection
is now disabled for tables using a storage engine (such as
NDB) that provides automatic partitioning. (Bug #14827952)
References: See also Bug #14672885.
* Replication: When using GTID-based replication, and whenever a
transaction was executed on the master but was not sent to the
slave because the slave already had a transaction with that
ID, semisynchrononous replication timed out. One case in which
this could happen was during a failover operation where the
new master started behind the new slave. (Bug #15985893)
* Replication: An unnecessary flush to disk performed after
every transaction when using FILE as the replication info
repository type could degrade performance. Now this is done
only when both data and relay log info is stored in
(transactional) tables. (Bug #15980626)
* Replication: Issuing START SLAVE UNTIL SQL_BEFORE_GTIDS =
gtid_set, where gtid_set covered a large number (tens or
hundreds of millions) of transactions, could cause the server
to hang. (Bug #15968413)
* Replication: When a slave was started using --skip-innodb and
replication info file repositories (FILE being the default for
both --relay-log-info-repository and
--master-info-repository), replication was incorrectly
stopped. However, if the slave is using file repositories and
not currently migrating between info repositories, replication
should be able to work without issues. Now the server ignores
errors raised when trying to open table info repositories in
such conditions.
In addition, binary log initialization was not performed
correctly when starting the slave with --skip-innodb, which
caused the --log-bin option to be ignored. (Bug #15956714, Bug
#67798, Bug #15971607)
* Replication: When temporary and persistent tables, or
temporary tables using different storage engines, are dropped
in a single statement, this statement is actually written as
two statements to the binary log, each represented by its own
log event. When gtid_mode is ON, each DDL event must have a
GTID; however, in such cases, the statement dropping the
temporary table was uncommitted, which meant that it was not
given its own GTID.
Now, when a DDL statement dropping a temporary table and a
table that is persistent, or that uses a different storage
engine, is separated in the manner just described, and the
resulting logged statement affecting only the temporary table
does not implicitly commit, a commit is forced so that the
corresponding log event has own unique GTID. (Bug #15947962)
* Replication: When used on a binary log that had been written
by a GTID-enabled server, mysqlbinlog did not correctly handle
transactions left unclosed by the omission of statements that
were ignored when the --database option was employed.
Now, whenever mysqlbinlog --database reads a GTID log event,
it checks to see whether there is an unclosed transaction, and
if so, issues a commit. (Bug #15912728)
* Replication: Semisynchronous replication did not work
correctly with GTIDs enabled. (Bug #15927032)
References: See also Bug #14737388.
* Replication: When GTIDs were enabled, the automatic dropping
of a temporary table when a client disconnected did not always
generate a GTID. Now each logged DROP TABLE statement,
including any generated by the server, is guaranteed to have
its own GTID. (Bug #15907504)
* Replication: After dropping a column from the slave's version
of a table, then altering the same column of this table on the
master (so that a type conversion would have been required had
the column not been droppped on the slave), inserts into this
table caused replication to fail. (Bug #15888454)
* Replication: SET GLOBAL sql_slave_skip_counter = 1 did not
skip errors or update the slave's position in the binary log
position when using --gtid-mode = ON. (Bug #15833516)
* Replication: When a binary log is replayed on a server (for
example, by executing a command like mysqlbinlog binlog.000001
| mysql), it sets a pseudo-slave mode on the client connection
used, so that the server can read binlog and apply binary log
events correctly. However, the pseudo-slave mode was not
disabled after the binary log dump was read, which caused
unexpected filtering rules to be applied to SQL statements
subsequently executed on the same connection. (Bug #15891524)
* Replication: During mysqld shutdown, global GTID variables
were released before it was made certain that all plugins had
stopped using them. (Bug #14798275)
* Replication: MASTER_POS_WAIT() could hang or return -1 due to
invalid updates by the slave SQL thread when transactions were
skipped by the GTID protocol. (Bug #14737388)
References: See also Bug #15927032.
* Replication: Trying to execute a Stop event on a multithreaded
slave could cause unwanted updates to the relay log, leading
the slave to lose synchronization with the master. (Bug
#14737388)
* Replication: Names of databases in binary log query log events
were not properly checked for length. (Bug #14636219)
* Replication: Issuing START SLAVE concurrently with setting
sql_slave_skip_counter or slave_net_timeout could cause a
deadlock. (Bug #14236151)
* Replication: When using statement-based replication, and where
the master and the slave used table schemas having different
AUTO_INCREMENT columns, inserts generating AUTO_INCREMENT
values logged for a given table on the master could be applied
to the wrong table on the slave. (Bug #12669186)
* Replication: Repeated execution of CHANGE MASTER TO statements
using invalid MASTER_LOG_POS values could lead to errors and
possibly a crash on the slave. Now in such cases, the
statement fails with a clear error message. (Bug #11764602,
Bug #57454)
* Microsoft Windows: Dynamic file names (with colons) are no
longer allowed. Static file names using the Alternate Data
Stream (ADS) NTFS functionality of Microsoft Windows may
continue to be used. (Bug #11761752)
* During client connection processing, the server now performs
password-expiration checking after SSL checks. (Bug #16103348)
* A buffer-handling problem in yaSSL was fixed. (Bug #15965288)
* The plugin logging routine mishandled its argument, resulting
in undefined behavior. (Bug #16002890)
* An ALTER TABLE with the ADD PRIMARY KEY or ADD UNIQUE INDEX
clause could encounter a serious error if the columns for the
primary key
(http://dev.mysql.com/doc/refman/5.6/en/glos_primary_key.html)
or unique index
(http://dev.mysql.com/doc/refman/5.6/en/glos_unique_index.html
) contained duplicate entries. This error occurred
intermittently, depending on how the rows were physically
distributed across index blocks. (Bug #15908291)
* The ALTER TABLE statement can now use the LOCK=NONE clause,
allowing online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
with concurrent DML
(http://dev.mysql.com/doc/refman/5.6/en/glos_dml.html), for
child tables
(http://dev.mysql.com/doc/refman/5.6/en/glos_child_table.html)
containing foreign key constraints
(http://dev.mysql.com/doc/refman/5.6/en/glos_foreign_key_const
raint.html). (Bug #15912214)
* In certain rare cases, a query using UpdateXML() could cause
the server to crash. (Bug #15948580)
References: See also Bug #13007062.
* AES_DECRYPT() and AES_ENCRYPT() had memory leaks when MySQL
was compiled using OpenSSL. (Bug #15909183)
* Several OpenSSL-related Valgrind warnings were corrected. (Bug
#15908967)
* Several OpenSSL-related memory leaks were fixed. (Bug
#15921729)
* Very long database names in queries could cause the server to
exit. (Bug #15912213)
* Within a stored procedure, executing a multiple-table DELETE
statement that used a very long table alias could cause the
server to exit. (Bug #15954896)
* Very long table aliases in queries could cause the server to
exit. (Bug #15948123)
* Metadata locking and table definition cache routines did not
always check length of names passed to them. (Bug #15954872)
* A comment added to mysqldump output for the --set-gid-purged
option was malformed and caused a syntax error when the dump
file was reloaded. (Bug #15922502)
References: See also Bug #14832472.
* Contention in the thread pool during kill processing could
lead to a Valgrind panic. (Bug #15921866)
* In the absence of a FULLTEXT index on an InnoDB table, a
full-text query with COUNT(*) could raise an assertion. (Bug
#15950531)
* If an error occurred during the final phase of an online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
operation, some cached metadata about the table might not be
restored to its original state. This issue typically affected
operations that renamed a column, and also dropped and
re-created an index on that column, in the same ALTER TABLE
statement. This issue did not affect operations that
reorganize the clustered index
(http://dev.mysql.com/doc/refman/5.6/en/glos_clustered_index.h
tml) of the table, such as adding a new primary key. (Bug
#15866734)
* In debug builds, the server could not start on 64-bit Windows
systems when a value of 16 GB or higher was specified for
innodb_buffer_pool_size. Non-debug builds would likely have
subtler issues, such as memory being allocated for the buffer
pool
(http://dev.mysql.com/doc/refman/5.6/en/glos_buffer_pool.html)
but not used, or read requests overlooking pages already
cached in the buffer pool.
On 32-bit Windows systems, the value of
innodb_buffer_pool_instances is increased if necessary so that
no buffer pool instance is larger then 1.3 GB, due to system
limitations on memory allocation. This automatic adjustment
needed for 32-bit Windows systems was incorrectly applied to
64-bit systems also; for systems with 16 GB or larger buffer
pools, the adjusted value of innodb_buffer_pool_instances
would exceed the upper limit of 64, causing an assertion error
in debug builds. (Bug #15883071)
* A heavy workload of online DDL
(http://dev.mysql.com/doc/refman/5.6/en/glos_online_ddl.html)
and concurrent DML
(http://dev.mysql.com/doc/refman/5.6/en/glos_dml.html) on a
table on a master
(http://dev.mysql.com/doc/mysql-monitor/2.3/en/glossary.html#g
los_master) server could cause errors as the changes were
replicated to slave
(http://dev.mysql.com/doc/mysql-monitor/2.3/en/glossary.html#g
los_slave) servers. For example, processing a DROP COLUMN
operation at the same time as queries referring to the dropped
column could cause errors on slave servers if the statements
finished in a different order than on the master. (Bug
#15878880)
* If the server shut down unexpectedly, the presence of an
InnoDB table with 1018 columns (very close to the upper limit
of 1020 columns) could cause an assertion error during server
restart:
InnoDB: Failing assertion: table->n_def == table->n_cols - 3
(Bug #15834685)
* The Performance Schema normally ignores temporary table
events. User-defined temporary tables are truncated by being
re-created, but the Performance Schema did not recognize
re-created temporary tables as being temporary and raised an
assertion. (Bug #15884836)
* The Performance Schema session_connect_attrs table displayed
extraneous information. (Bug #15864703)
* Subqueries with COUNT(DISTINCT ...)) could cause the server to
exit. (Bug #15832620)
References: See also Bug #11750963.
* Rows_log_event allocated one too few bytes for the row buffer.
(Bug #15890178)
* For the LooseScan semi-join strategy, the optimizer could rely
on an uninitialized variable. (Bug #15849654)
* For debug builds, an assertion could be raised when: 1) A view
was based on a MEMORY table; 2) The table was altered to drop
some column in use by the view; 3) A SELECT was done on the
view with binary logging disabled. (Bug #15847447)
* If loose index scan was used on a query with descending order,
the result set contained NULL values instead of the correct
values. (Bug #15848665)
* The optimizer's cost-based choice between IN -> EXISTS
subquery transformation and subquery materialization was
sometimes incorrect if the IN predicate was OR-ed with some
other predicate. (Bug #15866339)
References: See also Bug #13111584.
* In some cases, a cost value was printed to Optimizer Trace
output without being initialized, resulting in incorrect
output. (Bug #15877453)
* Several code issues identified by Fortify were corrected. (Bug
#15884324)
* Some queries, if used as prepared statements, caused the
server to exit if an error occurred. (Bug #15877062)
* Complex IN subqueries could cause the server to exit. (Bug
#15877738)
* It was possible to expire the password for an account even if
the account is authenticated by an authentication plugin that
does not support password expiration. (Bug #15849009)
* When the server reads the mysql.user table, it now checks for
invalid native and old-native password hashes and ignores
accounts with invalid hashes. (Bug #14845445)
* The validate_password plugin did not check certain passwords.
(Bug #14843970)
* GRANT ... IDENTIFIED BY could fail to flush the privileges.
(Bug #14849959)
* Setting the validate_password_length system variable did not
take into account that the minimum value is a function of
several other related system variables. Now the server will
not set the value less than the value of this expression:
validate_password_number_count
+ validate_password_special_char_count
+ (2 * validate_password_mixed_case_count)
(Bug #14850601)
* When used with an XPath expression that contained the output
of a stored function, ExtractValue() failed with the error
Only constant XPATH queries are supported. (Bug #14798445, Bug
#67313)
* MySQL could encounter an error during shutdown on Windows XP
or earlier systems. This issue did not affect systems running
Windows Vista or higher, which use atomic condition variables
to represent Windows Events. (Bug #14822849)
* Temporary table creation during execution of
INFORMATION_SCHEMA queries could result in Valgrind warnings.
(Bug #14801497)
* mysqladmin did not properly process commands for users with
expired passwords. (Bug #14833621)
* XA START had a race condition that could cause a server crash.
(Bug #14729757)
* The server could halt with an assertion error due to a
recently added error code:
InnoDB: unknown error code 1502
InnoDB: Assertion failure in thread thread_num in file row0mysql.cc l
ine 683
mysqld got signal 6 ;
Now, the server returns the error code DB_DICT_CHANGED to the
client in this case. (Bug #14764015)
* Queries that used grouping failed when executed using a cursor
if the optimizer processed the grouping using a temporary
table. (Bug #14740889)
* The server could exit when the MyISAM storage engine (rather
than MEMORY) was used to materialize a derived table. (Bug
#14728469)
* The sha256_password authentication plugin requires that the
client connect either using SSL or have RSA enabled. When
neither condition was met, an uninformative error message was
produced. Now the error message is more informative. (Bug
#14751925)
* The server now logs warnings at startup if the file specified
for the validate_password_dictionary_file system variable
violates constraints on valid password file contents. (Bug
#14588148)
* At startup, some InnoDB boolean system variables could be set
to 1 or 0, but not ON or OFF. These included
innodb_file_per_table, innodb_force_load_corrupted, and
innodb_large_prefix. (Bug #14494893)
* Output generated with mysqldump --routines could produce
syntax errors when reloaded. (Bug #14463669)
* Calculations involving self-intersecting polygons caused an
assertion to be raised. (Bug #14503584)
* If ALTER TABLE was killed, the server could report
ER_QUERY_INTERRUPTED even if the alterations had been made
successfully. This is misleading to the user. Also, the
statement would not be written to the binary log, leading to
incorrect replication (Bug #14382643)
* The parser failed to return an error for some invalid UNION
constructs. (Bug #13992148)
* Preloading of client plugins specified with the
LIBMYSQL_PLUGINS environment variable could fail unless the
plugins were located in the hardwired default plugin
directory. The C API now checks during plugin preloading for a
LIBMYSQL_PLUGIN_DIR environment variable which can be set to
the path name of the directory in which to look for client
plugins.
In addition, for explicit client plugin loading, the
mysql_load_plugin() and mysql_load_plugin_v() C API functions
have been modified to use the LIBMYSQL_PLUGIN_DIR value if it
exists and the --plugin-dir option was not given. If
--plugin-dir is given, mysql_load_plugin() and
mysql_load_plugin_v() ignore LIBMYSQL_PLUGIN_DIR. (Bug
#13994567)
* With the ONLY_FULL_GROUP_BY SQL mode enabled, executing a
stored function twice that contains a SQL query that is not
valid with that mode enabled caused the server to exit. (Bug
#13996639)
* Autosizing of Performance Schema parameters could result in
settings that caused excessive CPU use. (Bug #67736, Bug
#15927744)
* The optimizer sometimes chose a nonoptimimal range scan
strategy when a query included a LIMIT clause. (Bug #67432,
Bug #15829358)
* Full-text searches in InnoDB tables could return incorrect
results. (Bug #67257, Bug #14771282)
* The mysql client could mishandle the delimiter command if it
occurred on a line during which mysql was looking for the end
of a quoted string. (Bug #64135, Bug #13639125)
* The Performance Schema normally ignores temporary table
events, but sometimes failed to properly identify a table as
temporary and consequently recorded events for the table. (Bug
#67098, Bug #14756887)
* Some messages written by the server to the error log referred
to the deprecated --log-slow-queries option rather than the
--slow-query-log option. Similarly, the server referred to the
deprecated --log option rather than the --general-log-file and
--log-output options. (Bug #67892, Bug #15996571)
* Attempting to perform an in-place upgrade from MySQL 5.1 to
5.6 causes the server to exit due to a mismatch between the
privilege structures in the two series. (This is not a
supported operation, but the server should not exit
ungracefully.) (Bug #67319, Bug #14826854)
* DECIMAL multiplication operations could produce significant
inaccuracy. (Bug #45860, Bug #11754279)
* Due to a thread race condition, the server could exit while
attempting to read the Performance Schema
threads.PROCESSLIST_INFO column. (Bug #68127, Bug #16196158)
* The optimizer could choose an IN-to-EXISTS transformation for
subquery execution in some cases when subquery materialization
would be cheaper. (Bug #67511, Bug #15848521)
* It is not permitted to use CREATE TABLE to create an NDB table
with user-defined partitioning and a foreign key. However, it
was possible to create an NDB table with a foreign key, then
add partitioning to it using ALTER TABLE, thus creating a
table which was impossible to backup/restore using mysqldump.
Now the prohibition is enforced consistently. (Bug #67492, Bug
#15844519)
* For single-table DELETE or UPDATE statements, EXPLAIN
displayed a type value of ALL (full-table scan access method)
even if the optimizer chose to scan the table by an index
access method. Now the type value is displayed as index. (Bug
#67637, Bug #15892875)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ius/+bug/1117674/+subscriptions
References
