MySQL-shared-compat-advanced-gpl-5.1.31-0.*.rpm and MySQL-shared-compat-advanced-5.1.31-0.*.rpm packages are now available. These client library compatibility packages are like the MySQL-shared-compat package, but are for the “MySQL Enterprise Server –dash; Advanced Edition” products. Install these packages rather than the normal MySQL-shared-compat package if you want to included shared client libraries for older MySQL versions. (Bug#41838)

A new status variable, Queries, indicates the number of statements executed by the server. This includes statements executed within stored programs, unlike the Questions variable which includes only statements sent to the server by clients. (Bug#41131)

Performance of SELECT * retrievals from INFORMATION_SCHEMA.COLUMNS was improved slightly. (Bug#38918)

Previously, index hints did not work for FULLTEXT searches. Now they work as follows:

For natural language mode searches, index hints are silently ignored. For example, IGNORE INDEX(i) is ignored with no warning and the index is still used.

For boolean mode searches, index hints with FOR ORDER BY or FOR GROUP BY are silently ignored. Index hints with FOR JOIN or no FOR modifier are honored. In contrast to how hints apply for non-FULLTEXT searches, the hint is used for all phases of query execution (finding rows and retrieval, grouping, and ordering). This is true even if the hint is given for a non-FULLTEXT index. (Bug#38842)

Important Change: Replication: If a trigger was defined on an InnoDB table and this trigger updated a nontransactional table, changes performed on the InnoDB table were replicated and were visible on the slave before they were committed on the master, and were not rolled back on the slave after a successful rollback of those changes on the master.

As a result of the fix for this issue, the semantics of mixing nontransactional and transactional tables in a transaction in the first statement of a transaction have changed. Previously, if the first statement in a transaction contained nontransactional changes, the statement was written directly to the binary log. Now, any statement appearing after a BEGIN (or immediately following a COMMIT if AUTOCOMMIT = 0) is always considered part of the transaction and cached. This means that nontransactional changes do not propagate to the slave until the transaction is committed and thus written to the binary log.

See Section 16.3.1.26, “Replication and Transactions”, for more information about this change in behavior. (Bug#40116)

Partitioning: Replication: Changing the transaction isolation level while replicating partitioned InnoDB tables could cause statement-based logging to fail. (Bug#39084)

Partitioning: A comparison with an invalid DATE value in a query against a partitioned table could lead to a crash of the MySQL server.

(Bug#40972)

Partitioning: This bug was introduced in MySQL 5.1.29. (Bug#40954)

This regression was introduced by Bug#30573, Bug#33257, Bug#33555.

Partitioning: With READ COMMITTED transaction isolation level, InnoDB uses a semi-consistent read that releases nonmatching rows after MySQL has evaluated the WHERE clause. However, this was not happening if the table used partitions. (Bug#40595)

Partitioning: A query that timed out when run against a partitioned table failed silently, without providing any warnings or errors, rather than returning Lock wait timeout exceeded. (Bug#40515)

Partitioning: ALTER TABLE ... REORGANIZE PARTITION could crash the server when the number of partitions was not changed. (Bug#40389)

See also Bug#41945.

Partitioning: For a partitioned table having an AUTO_INCREMENT column: If the first statement following a start of the server or a FLUSH TABLES statement was an UPDATE statement, the AUTO_INCREMENT column was not incremented correctly. (Bug#40176)

Partitioning: The server attempted to execute the statements ALTER TABLE ... ANALYZE PARTITION, ALTER TABLE ... CHECK PARTITION, ALTER TABLE ... OPTIMIZE PARTITION, and ALTER TABLE ... REORGANIZE PARTITION on tables that were not partitioned. (Bug#39434)

See also Bug#20129.

Partitioning: The value of the CREATE_COLUMNS column in INFORMATION_SCHEMA.TABLES was not partitioned for partitioned tables. (Bug#38909)

Partitioning: When executing an ORDER BY query on a partitioned InnoDB table using an index that was not in the partition expression, the results were sorted on a per-partition basis rather than for the table as a whole. (Bug#37721)

Partitioning: Dropping or creating an index on a partitioned table managed by the InnoDB Plugin locked the table. (Bug#37453)

Partitioning: Partitioned table checking sometimes returned a warning with an error code of 0, making proper response to errors impossible. The fix also renders the error message subject to translation in non-English deployments. (Bug#36768)

Partitioning: SHOW TABLE STATUS could show a nonzero value for the Mean record length of a partitioned InnoDB table, even if the table contained no rows. (Bug#36312)

Partitioning: When SHOW CREATE TABLE was used on a partitioned table, all of the table's PARTITION and SUBPARTITION clauses were output on a single line, making it difficult to read or parse. (Bug#14326)

Replication: Per-table AUTO_INCREMENT option values were not replicated correctly for InnoDB tables. (Bug#41986)

Replication: Some log_event types did not skip the post-header when reading. (Bug#41961)

Replication: Attempting to read a binary log containing an Incident_log_event having an invalid incident number could cause the debug server to crash. (Bug#40482)

Replication: When using row-based replication, an update of a primary key that was rolled back on the master due to a duplicate key error was not rolled back on the slave. (Bug#40221)

Replication: When rotating relay log files, the slave deletes relay log files and then edits the relay log index file. Formerly, if the slave shut down unexpectedly between these two events, the relay log index file could then reference relay logs that no longer existed. Depending on the circumstances, this could when restarting the slave cause either a race condition or the failure of replication. (Bug#38826, Bug#39325)

Replication: With row-based replication, UPDATE and DELETE statements using LIMIT and a table's primary key could produce different results on the master and slave. (Bug#38230)

resolve_stack_dump was unable to resolve the stack trace format produced by mysqld in MySQL 5.1 and up (see Section 21.5.1.5, “Using a Stack Trace”). (Bug#41612)

In example option files provided in MySQL distributions, the thread_stack value was increased from 64K to 128K. (Bug#41577)

The optimizer could ignore an error and rollback request during a filesort, causing an assertion failure. (Bug#41543)

DATE_FORMAT() could cause a server crash for year-zero dates. (Bug#41470)

SET PASSWORD caused a server crash if the account name was given as CURRENT_USER(). (Bug#41456)

When a repair operation was carried out on a CSV table, the debug server crashed. (Bug#41441)

When substituting system constant functions with a constant result, the server was not expecting NULL function return values and could crash. (Bug#41437)

Queries such as SELECT ... CASE AVG(...) WHEN ... that used aggregate functions in a CASE expression crashed the server. (Bug#41363)

INSERT INTO .. SELECT ... FROM and CREATE TABLE ... SELECT ... FROM a TEMPORARY table could inadvertently change the locking type of the temporary table from a write lock to a read lock, causing statement failure. (Bug#41348)

The INFORMATION_SCHEMA.SCHEMA_PRIVILEGES table was limited to 7680 rows. (Bug#41079)

In debug builds, obsolete debug code could be used to crash the server. (Bug#41041)

Some queries that used a “range checked for each record” scan could return incorrect results. (Bug#40974)

See also Bug#44810.

Certain SELECT queries could fail with a Duplicate entry error. (Bug#40953)

For debug servers, OPTIMIZE TABLE on a compressed table caused a server crash. (Bug#40949)

Accessing user variables within triggers could cause a server crash. (Bug#40770)

IF(..., CAST(longtext_val AS UNSIGNED), signed_val) as an argument to an aggregate function could cause an assertion failure. (Bug#40761)

For single-table UPDATE statements, an assertion failure resulted from a runtime error in a stored function (such as a recursive function call or an attempt to update the same table as in the UPDATE statement). (Bug#40745)

TRUNCATE TABLE for an InnoDB table did not flush cached queries for the table. (Bug#40386)

Prepared statements allowed invalid dates to be inserted when the ALLOW_INVALID_DATES SQL mode was not enabled. (Bug#40365)

mc.exe is no longer needed to compile MySQL on Windows. This makes it possible to build MySQL from source using Visual Studio Express 2008. (Bug#40280)

The ':' character was incorrectly disallowed in table names. (Bug#40104)

Support for the revision field in .frm files has been removed. This addresses the downgrading problem introduced by the fix for Bug#17823. (Bug#40021)

Retrieval speed from the following INFORMATION_SCHEMA tables was improved by shortening the VARIABLE_VALUE column to 1024 characters: GLOBAL_VARIABLES, SESSION_VARIABLES, GLOBAL_STATUS, and SESSION_STATUS.

As a result of this change, any variable value longer than 1024 characters will be truncated with a warning. This affects only the init_connect system variable. (Bug#39955)

For an InnoDB table, DROP TABLE or ALTER TABLE ... DISCARD TABLESPACE could take a long time or cause a server crash. (Bug#39939)

If the operating system is configured to return leap seconds from OS time calls or if the MySQL server uses a time zone definition that has leap seconds, functions such as NOW() could return a value having a time part that ends with :59:60 or :59:61. If such values are inserted into a table, they would be dumped as is by mysqldump but considered invalid when reloaded, leading to backup/restore problems.

Now leap second values are returned with a time part that ends with :59:59. This means that a function such as NOW() can return the same value for two or three consecutive seconds during the leap second. It remains true that literal temporal values having a time part that ends with :59:60 or :59:61 are considered invalid.

For additional details about leap-second handling, see Section 9.7.2, “Time Zone Leap Second Support”. (Bug#39920)

The server could crash during a sort-order optimization of a dependent subquery. (Bug#39844)

For a server started with the --temp-pool option on Windows, temporary file creation could fail. This option now is ignored except on Linux systems, which was its original intended scope. (Bug#39750)

ALTER TABLE on a table with FULLTEXT index that used a pluggable FULLTEXT parser could cause debug servers to crash. (Bug#39746)

With the ONLY_FULL_GROUP_BY SQL mode enabled, the check for nonaggregated columns in queries with aggregate functions, but without a GROUP BY clause was treating all the parts of the query as if they were in the select list. This is fixed by ignoring the nonaggregated columns in the WHERE clause. (Bug#39656)

The server crashed if an integer field in a CSV file did not have delimiting quotes. (Bug#39616)

Creating a table with a comment of 62 characters or longer caused a server crash. (Bug#39591)

The do_abi_check program run during the build process depends on mysql_version.h but that file was not created first, resulting in build failure. (Bug#39571)

CHECK TABLE failed for MyISAM INFORMATION_SCHEMA tables. (Bug#39541)

On 64-bit Windows systems, the server accepted key_buffer_size values larger than 4GB, but allocated less. (For example, specifying a value of 5GB resulted in 1GB being allocated.) (Bug#39494)

InnoDB could hang trying to open an adaptive hash index. (Bug#39483)

Following ALTER TABLE ... DISCARD TABLESPACE for an InnoDB table, an attempt to determine the free space for the table before the ALTER TABLE operation had completely finished could cause a server crash. (Bug#39438)

Use of the PACK_KEYS or MAX_ROWS table option in ALTER TABLE should have triggered table reconstruction but did not. (Bug#39372)

The server returned a column type of VARBINARY rather than DATE as the result from the COALESCE(), IFNULL(), IF(), GREATEST(), or LEAST() functions or CASE expression if the result was obtained using filesort in an anonymous temporary table during the query execution. (Bug#39283)

A server built using yaSSL for SSL support would crash if configured to use an RSA key and a client sent a cipher list containing a non-RSA key as acceptable. (Bug#39178)

When built with Valgrind, the server failed to access tables created with the DATA DIRECTORY or INDEX DIRECTORY table option. (Bug#39102)

With binary logging enabled CREATE VIEW was subject to possible buffer overwrite and a server crash. (Bug#39040)

The fast mutex implementation was subject to excessive lock contention. (Bug#38941)

Use of InnoDB monitoring (SHOW ENGINE INNODB STATUS or one of the InnoDB Monitor tables) could cause a server crash due to invalid access to a shared variable in a concurrent environment. (Bug#38883)

InnoDB could fail to generate AUTO_INCREMENT values after an UPDATE statement for the table. (Bug#38839)

If delayed insert failed to upgrade the lock, it did not free the temporary memory storage used to keep newly constructed BLOB values in memory, resulting in a memory leak. (Bug#38693)

On Windows, a five-second delay occurred at shutdown of applications that used the embedded server. (Bug#38522)

On Solaris, a scheduling policy applied to the main server process could be unintentionally overwritten in client-servicing threads. (Bug#38477)

Building MySQL on FreeBSD would result in a failure during the gen_lex_hash phase of the build. (Bug#38364)

On Windows, the embedded server would crash in mysql_library_init() if the language file was missing. (Bug#38293)

A mix of TRUNCATE TABLE with LOCK TABLES and UNLOCK TABLES for an InnoDB could cause a server crash. (Bug#38231)

The ExtractValue() function did not work correctly with XML documents containing a DOCTYPE declaration. (Bug#38227)

Queries with a HAVING clause could return a spurious row. (Bug#38072)

The Event Scheduler no longer logs “started in thread” or “executed” successfully messages to the error log. (Bug#38066)

Use of spatial data types in prepared statements could cause memory leaks or server crashes. (Bug#37956, Bug#37671)

An error in a debugging check caused crashes in debug servers. (Bug#37936)

A SELECT with a NULL NOT IN condition containing a complex subquery from the same table as in the outer select caused an assertion failure. (Bug#37894)

The presence of a /* ... */ comment preceding a query could cause InnoDB to use unnecessary gap locks. (Bug#37885)

Use of an uninitialized constant in EXPLAIN evaluation caused an assertion failure. (Bug#37870)

When using ALTER TABLE on an InnoDB table, the AUTO_INCREMENT value could be changed to an incorrect value. (Bug#37788)

Primary keys were treated as part of a covering index even if only a prefix of a key column was used. (Bug#37742)

Renaming an ARCHIVE table to the same name with different lettercase and then selecting from it could cause a server crash. (Bug#37719)

The MONTHNAME() and DAYNAME() functions returned a binary string, so that using LOWER() or UPPER() had no effect. Now MONTHNAME() and DAYNAME() return a value in character_set_connection character set. (Bug#37575)

TIMEDIFF() was erroneously treated as always returning a positive result. Also, CAST() of TIME values to DECIMAL dropped the sign of negative values. (Bug#37553)

See also Bug#42525.

SHOW PROCESSLIST displayed “copy to tmp table” when no such copy was occurring. (Bug#37550)

mysqlcheck used SHOW FULL TABLES to get the list of tables in a database. For some problems, such as an empty .frm file for a table, this would fail and mysqlcheck then would neglect to check other tables in the database. (Bug#37527)

Updating a view with a subquery in the CHECK option could cause an assertion failure. (Bug#37460)

Statements that displayed the value of system variables (for example, SHOW VARIABLES) expect variable values to be encoded in character_set_system. However, variables set from the command line such as basedir or datadir were encoded using character_set_filesystem and not converted correctly. (Bug#37339)

CREATE INDEX could crash with InnoDB plugin 1.0.1. (Bug#37284)

Certain boolean-mode FULLTEXT searches that used the truncation operator did not return matching records and calculated relevance incorrectly. (Bug#37245)

On a 32-bit server built without big tables support, the offset argument in a LIMIT clause might be truncated due to a 64-bit to 32-bit cast. (Bug#37075)

For an InnoDB table with a FOREIGN KEY constraint, TRUNCATE TABLE may be performed using row by row deletion. If an error occurred during this deletion, the table would be only partially emptied. Now if an error occurs, the truncation operation is rolled back and the table is left unchanged. (Bug#37016)

The code for the ut_usectime() function in InnoDB did not handle errors from the gettimeofday() system call. Now it retries gettimeofday() several times and updates the value of the Innodb_row_lock_time_max status variable only if ut_usectime() was successful. (Bug#36819)

Use of CONVERT() with GROUP BY to convert numeric values to CHAR could return truncated results. (Bug#36772)

The mysql client, when built with Visual Studio 2005, did not display Japanese characters. (Bug#36279)

CREATE INDEX for InnoDB tables could under very rare circumstances cause the server to crash.. (Bug#36169)

A read past the end of the string could occur while parsing the value of the --innodb-data-file-path option. (Bug#36149)

Setting the slave_compressed_protocol system variable to DEFAULT failed in the embedded server. (Bug#35999)

For upgrades to MySQL 5.1 or higher, mysql_upgrade did not re-encode database or table names that contained nonalphanumeric characters. (They would still appear after the upgrade with the #mysql50# prefix described in Section 8.2.3, “Mapping of Identifiers to File Names”.) To correct this problem, it was necessary to run mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names manually. mysql_upgrade now runs that command automatically after performing the initial upgrade. (Bug#35934)

SHOW CREATE TABLE did not display a printable value for the default value of BIT columns. (Bug#35796)

The columns that store character set and collation names in several INFORMATION_SCHEMA tables were lengthened because they were not long enough to store some possible values: SCHEMATA, TABLES, COLUMNS, CHARACTER_SETS, COLLATIONS, and COLLATION_CHARACTER_SET_APPLICABILITY. (Bug#35789)

The max_length metadata value was calculated incorrectly for the FORMAT() function, which could cause incorrect result set metadata to be sent to clients. (Bug#35558)

InnoDB was not updating the Handler_delete or Handler_update status variables. (Bug#35537)

InnoDB could fail to generate AUTO_INCREMENT values if rows previously had been inserted containing literal values for the AUTO_INCREMENT column. (Bug#35498, Bug#36411, Bug#39830)

The CREATE_OPTIONS column for INFORMATION_SCHEMA.TABLES did not display the KEY_BLOCK_SIZE option. (Bug#35275)

Selecting from an INFORMATION_SCHEMA table into an incorrectly defined MERGE table caused an assertion failure. (Bug#35068)

perror on Windows did not know about Win32 system error codes. (Bug#34825)

EXPLAIN EXTENDED evaluation of aggregate functions that required a temporary table caused a server crash. (Bug#34773)

SHOW GLOBAL STATUS shows values that aggregate the session status values for all threads. This did not work correctly for the embedded server. (Bug#34517)

mysqldumpslow did not aggregate times. (Bug#34129)

mysql_config did not output -ldl (or equivalent) when needed for --libmysqld-libs, so its output could be insufficient to build applications that use the embedded server. (Bug#34025)

The mysql client incorrectly parsed statements containing the word “delimiter” in mid-statement.

This fix is different from the one applied for this bug in MySQL 5.1.26. (Bug#33812)

See also Bug#38158.

For a stored procedure containing a SELECT * ... RIGHT JOIN query, execution failed for the second call. (Bug#33811)

Previously, use of index hints with views (which do not have indexes) produced the error ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX and VIEW. Now this produces ERROR 1176 (HY000): Key '...' doesn't exist in table '...', the same error as for base tables without an appropriate index. (Bug#33461)

Three conditions were discovered that could cause an upgrade from MySQL 5.0 to 5.1 to fail: 1) Triggers associated with a table that had a #mysql50# prefix in the name could cause assertion failure. 2) ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME failed for databases that had a #mysql50# prefix if there were triggers in the database. 3) mysqlcheck --fix-table-name didn't use UTF8 as the default character set, resulting in parsing errors for tables with nonlatin symbols in their names and trigger definitions. (Bug#33094, Bug#41385)

Execution of a prepared statement that referred to a system variable caused a server crash. (Bug#32124)

Some division operations produced a result with incorrect precision. (Bug#31616)

Queries executed using join buffering of BIT columns could produce incorrect results. (Bug#31399)

ALTER TABLE CONVERT TO CHARACTER SET did not convert TINYTEXT or MEDIUMTEXT columns to a longer text type if necessary when converting the column to a different character set. (Bug#31291)

Server variables could not be set to their current values on Linux platforms. (Bug#31177)

See also Bug#6958.

For installation on Solaris using pkgadd packages, the mysql_install_db script was generated in the scripts directory, but the temporary files used during the process were left there and not deleted. (Bug#31052)

Static storage engines and plugins that were disabled and dynamic plugins that were installed but disabled were not listed in the INFORMATION_SCHEMA appropriate PLUGINS or ENGINES table. (Bug#29263)

Some SHOW statements and retrievals from the INFORMATION_SCHEMA TRIGGERS and EVENTS tables used a temporary table and incremented the Created_tmp_disk_tables status variable, due to the way that TEXT columns are handled. The TRIGGERS.SQL_MODE, TRIGGERS.DEFINER, and EVENTS.SQL_MODE columns now are VARCHAR to avoid this problem. (Bug#29153)

For several read only system variables that were viewable with SHOW VARIABLES, attempting to view them with SELECT @@var_name or set their values with SET resulted in an unknown system variable error. Now they can be viewed with SELECT @@var_name and attempting to set their values results in a message indicating that they are read only. (Bug#28234)

On Windows, Visual Studio does not take into account some x86 hardware limitations, which led to incorrect results converting large DOUBLE values to unsigned BIGINT values. (Bug#27483)

SSL support was not included in some “generic” RPM packages. (Bug#26760)

The Questions status variable is intended as a count of statements sent by clients to the server, but was also counting statements executed within stored routines. (Bug#24289)

Setting the session value of the max_allowed_packet or net_buffer_length system variable was allowed but had no effect. The session value of these variables is now read only. (Bug#22891)

See also Bug#32223.

A race condition between the mysqld.exe server and the Windows service manager could lead to inability to stop the server from the service manager. (Bug#20430)

On Windows, moving an InnoDB .ibd file and then symlinking to it in the database directory using a .sym file caused a server crash. (Bug#11894)