This is a Service Pack release of the MySQL Enterprise Server 5.0.
This section documents all changes and bugfixes that have been applied in MySQL 5.0.56sp1 since the previous MySQL Enterprise Server Quarterly Service Pack release (5.0.50sp1a). If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details please see http://www.mysql.com/products/enterprise/advisors.html.
mysqldump produces a
completed on comment
at the end of the dump if
--comments is given. The date
causes dump files for identical data take at different times to
appear to be different. The new options
control whether the date is added to the comment.
suppresses date printing. The default is
--dump-date (include the date
in the comment).
mysql_odbc_escape_string() C API
function has been removed. It has multibyte 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.
References: See also Bug #41728.
The default value of the
connect_timeout system variable
was increased from 5 to 10 seconds. This might help in cases
where clients frequently encounter errors of the form
Lost connection to MySQL server at
XXX', system error:
The argument for the mysql-test-run.pl
options is now interpreted as a Perl regular expression if there
is a pattern metacharacter in the argument value. This enables
more flexible specification of which tests to perform or skip.
RENAME TABLE against a
table with explicit
DATA DIRECTORY and
INDEX DIRECTORY options can be used to
overwrite system table information by replacing the symbolic
link points. the file to which the symlink points.
MySQL will now return an error when the file to which the symlink points already exists. (Bug #32111, CVE-2007-5969)
ALTER VIEW retained the original
DEFINER value, even when altered by another
user, which could enable that user to gain the access rights of
the view. Now
ALTER VIEW is
permitted only to the original definer or users with the
When using a
FEDERATED table, the local
server could be forced to crash if the remote server returned a
result with fewer columns than expected.
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)
InnoDB had a race condition for an adaptive
hash rw-lock waiting for an X-lock. This fix may also provide
significant speed improvements on systems experiencing problems
with contention for the adaptive hash index.
mode enabled, queries such as
SELECT a FROM t1 HAVING
COUNT(*)>2 were not being rejected as they should
This fix results in the following behavior:
There is a check against mixing group and nongroup columns
This check is done both for the select list and for the
HAVING clause if there is one.
This behavior differs from previous versions as follows:
Incompatible Change: The MySQL 5.0.50 patch for this bug was reverted because it changed the behavior of a General Availability MySQL release. (Bug #30234)
References: See also Bug #27525.
Incompatible Change: It was possible to create a view having a column whose name consisted of an empty string or space characters only.
One result of this bug fix is that aliases for columns in the
SELECT statement are checked to ensure
that they are legal column names. In particular, the length must
be within the maximum column length of 64 characters, not the
maximum alias length of 256 characters. This can cause problems
for replication or loading dump files. For additional
information and workarounds, see
Restrictions on Views.
References: See also Bug #31202.
Several type-preserving functions and operators returned an
incorrect result type that does not match their argument types:
CASE. These now aggregate using the
precise SQL types of their arguments rather than the internal
type. In addition, the result type of the
STR_TO_DATE() function is now
DATETIME by default.
Incompatible Change: It was possible for option files to be read twice at program startup, if some of the standard option file locations turned out to be the same directory. Now duplicates are removed from the list of files to be read.
Also, users could not override system-wide settings using
was read last. The latter file now is read earlier so that
~/.my.cnf can override system-wide
The fix for this problem had a side effect such that on Unix,
MySQL programs looked for options in
~/my.cnf rather than the standard location
~/.my.cnf. That problem is addressed in
Important Change; MySQL Cluster:
AUTO_INCREMENT columns had the following
problems when used in
AUTO_INCREMENT counter was not
updated correctly when such a column was updated.
AUTO_INCREMENT values were not
prefetched beyond statement boundaries.
AUTO_INCREMENT values were not handled
After being set,
showed a value of 1, regardless of the value it had
actually been set to.
As part of this fix, the behavior of
has changed. Setting this to less than 32 no longer has any
effect on prefetching within statements (where IDs are now
always obtained in batches of 32 or more), but only between
statements. The default value for this variable has also
changed, and is now
(Bug #25176, Bug #31956, Bug #32055)
Important Change; Replication:
When the master crashed during an update on a transactional
table while in
the slave failed. This fix causes every transaction (including
autocommit transactions) to be
recorded in the binary log as starting with a
ending with a
The current fix does not cause
nontransactional changes to be wrapped in
when written to the binary log. For this purpose, any
statements affecting tables using a nontransactional storage
engine such as
regarded as nontransactional, even when
autocommit is enabled.
References: See also Bug #29288, Bug #49522.
Important Note; Replication: 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)
An improperly reset internal signal was observed as a hang when
using events in the
NDB API but
could result in various errors.
MySQL Cluster: Incorrectly handled parameters could lead to a crash in the Transaction Coordinator during a node failure, causing other data nodes to fail. (Bug #33168)
MySQL Cluster: The failure of a master node could lead to subsequent failures in local checkpointing. (Bug #32160)
An uninitialized variable in the
NDB storage engine code led to
AUTO_INCREMENT failures when the server was
compiled with gcc 4.2.1.
References: This bug was introduced by Bug #27437.
An error with an
if statement in
sql/ha_ndbcluster.cc could potentially lead
to an infinite loop in case of failure when working with
AUTO_INCREMENT columns in
NDB storage engine code was not
safe for strict-alias optimization in gcc
Primary keys on variable-length columns (such as
VARCHAR) did not work correctly.
MySQL Cluster: Transaction timeouts were not handled well in some circumstances, leading to excessive number of transactions being aborted unnecessarily. (Bug #30379)
MySQL Cluster: In some cases, the cluster managment server logged entries multiple times following a restart of ndb_mgmd. (Bug #29565)
MySQL Cluster: An interpreted program of sufficient size and complexity could cause all cluster data nodes to shut down due to buffer overruns. (Bug #29390)
UPDATE IGNORE could sometimes fail on
NDB tables due to the use of
unitialized data when checking for duplicate keys to be ignored.
When inserting a row into an
table with a duplicate value for a nonprimary unique key, the
error issued would reference the wrong key.
This improves on an initial fix for this issue made in MySQL 5.0.30 and MySQL 5.0.33 (Bug #21072)
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 binary log; previously,
either of these occurrences could cause the slave to fail.
References: See also Bug #29749.
SQL statements containing comments using
syntax were not replayable by mysqlbinlog,
even though such statements replicated correctly.
Replication: It was possible for the name of the relay log file to exceed the amount of memory reserved for it, possibly leading to a crash of the server. (Bug #31836)
References: See also Bug #28597.
Replication: Corruption of log events caused the server to crash on 64-bit Linux systems having 4 GB or more of memory. (Bug #31793)
Use of the
@@hostname system variable in
not replicate. The workaround is to select its value into a user
variable (which does replicate) and insert that.
DROP VIEW statement
caused replication to fail if the view did not actually exist.
Replication: One thread could read uninitialized memory from the stack of another thread. This issue was only known to occur in a mysqld process acting as both a master and a slave. (Bug #30752)
server_id did not
update its value for the current session.
Replication: Due a previous change in how the default name and location of the binary log file were determined, replication failed following some upgrades. (Bug #28597, Bug #28603)
References: See also Bug #31836. This bug was introduced by Bug #20166.
Stored procedures having
parameters were not replicated correctly.
SHOW SLAVE STATUS as
mysqld was shutting down could cause a crash.
UPDATE statement using a
stored function that modified a nontransactional table was not
logged if it failed. This caused the copy of the
nontransactional table on the master have a row that the copy on
the slave did not.
In addition, when an
ON DUPLICATE KEY UPDATE statement encountered a
duplicate key constraint, but the
UPDATE did not actually change
any data, the statement was not logged. As a result of this fix,
such statements are now treated the same for logging purposes as
UPDATE statements, and so
are written to the binary log.
References: See also Bug #12713.
A replication slave sometimes failed to reconnect because it was
unable to run
SHOW SLAVE HOSTS.
It was not necessary to run this statement on slaves (since the
master should track connection IDs), and the execution of this
statement by slaves was removed.
References: See also Bug #13963, Bug #21869.
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
Use of uninitialized memory for
filesort in a
subquery caused a server crash.
The parser permitted control structures in compound statements to have mismatched beginning and ending labels. (Bug #33618)
SET GLOBAL myisam_max_sort_file_size=DEFAULT
to an incorrect value.
References: See also Bug #31177.
CREATE TABLE ...
SELECT created tables that for date columns used the
Field_date type instead of
References: See also Bug #33402, Bug #30617.
could not be used as views due to incorrect column reference
The fix for Bug #11230 and Bug #26215 introduced a significant input-parsing slowdown for the mysql client. This has been corrected. (Bug #33057)
UNION constructs cannot contain
INTO except in the final
SELECT. However, if a
UNION was used in a subquery and
INTO clause appeared in the top-level
query, the parser interpreted it as having appeared in the
UNION and raised an error.
The correct data type for a
resulting from a
UNION could be
determined incorrectly in some cases: 1) Not correctly inferred
NULL depending on the number of selects;
2) Not inferred correctly as
NULL if one
select used a subquery.
ORDER BY query using
NULL in the
WHERE clause did not
return correct results.
For queries containing
, there was a
limitation that the
col_list ORDER BY
DISTINCT columns had to
be the same as
ORDER BY columns. Incorrect
results could be returned if this was not true.
Use of the
cp932 character set with
CAST() in an
BY clause could cause a server crash.
A subquery using an
IS NULL check of a column
NOT NULL in a table used in the
FROM clause of the outer query produced an
Specifying a nonexistent column for an
INSERT DELAYED statement caused a
server crash rather than producing an error.
libmysqld to crash.
NULL values in the value
Use of a
BY expression in conjunction with
ROLLUP could cause a server crash.
References: See also Bug #31095.
SELECT ... GROUP BY
with an assertion if the length of the
BIT column used for the
GROUP BY was not an integer multiple of 8.
SELECT INTO OUTFILE with 8-bit
ENCLOSED BY characters led to corrupted data
when the data was reloaded using LOAD DATA INFILE. This was
SELECT INTO OUTFILE failed to escape
the 8-bit characters.
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.
A build problem introduced in MySQL 5.0.52 was resolved: The x86 32-bit Intel icc-compiled server binary had unwanted dependences on Intel icc runtime libraries. (Bug #32514)
The rules for valid column names were being applied differently for base tables and views. (Bug #32496)
QUERY statements to target a connection running
SELECT SLEEP() could freeze the server.
ssl-cipher values in option files were not
being read by
Repeated execution of a query containing a
CASE expression and numerous
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.
Referencing within a subquery an alias used in the
SELECT list of the outer query
was incorrectly permitted.
ORDER BY query on a view created using a
FEDERATED table as a base table caused the
server to crash.
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).
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.
Memory corruption could occur due to large index map in
Range checked for each record status reported
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.
Various test program cleanups were made: 1)
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
The default grant tables on Windows contained information for
production.mysql.com, which should not
Under certain conditions, the presence of a
BY clause could cause an
clause to be ignored.
For comparisons of the form
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.
InnoDB does not support
SPATIAL indexes, but could crash when asked
to handle one. Now an error is returned.
CREATE TABLE LIKE was treated
libmysqld than by the
Within a subquery,
handled differently than at the top level, which could result in
incorrect results or a server crash.
(Bug #32036, Bug #32051)
User-defined functions are not loaded if the server is started
option, but the server did not properly handle this case and
issued an Out of memory error message
A column with malformed multibyte characters could cause the full-text parser to go into an infinite loop. (Bug #31950)
Changing the SQL mode to cause dates with “zero”
parts to be considered invalid (such as
'1000-00-00') could result in indexed and
nonindexed searches returning different results for a column
that contained such dates.
In debug builds, testing the result of an
NULL caused an assertion
mysql-test-run.pl sometimes set up test scenarios in which the same port number was passed to multiple servers, causing one of them to be unable to start. (Bug #31880)
Comparison results for
different from those for operators like
DATETIME-like values with
trailing extra characters such as
the values as
the other operators performed a binary-string comparison. Now
they all uniformly use a
comparison, but generate warnings for values with trailing
Name resolution for correlated subqueries and
HAVING clauses failed to distinguish which of
two was being performed when there was a reference to an outer
aliased field. This could result in error messages about a
HAVING clause for queries that had no such
For a fatal error during a filesort in
find_all_keys(), the error was returned
without the necessary handler uninitialization, causing an
The examined-rows count was not incremented for
mysql_change_user() C API
function was subject to buffer overflow.
SELECT ... INTO
OUTFILE, if the
ENCLOSED BY string
is empty and the
FIELDS TERMINATED BY string
started with a special character (one of
N), every occurrence
of the character within field values would be duplicated.
The mysqlbug script did not include the
correct values of
CXXFLAGS that were used to configure the
ucs2 does not work as a client character set,
but attempts to use it as such were not rejected. Now
character_set_client cannot be
ucs2. This also affects statements
SET NAMES and
A buffer used when setting variables was not dimensioned to
accommodate the trailing
'\0' byte, so a
single-byte buffer overrun was possible.
HAVING could treat lettercase of table
aliases incorrectly if
The fix for Bug #24989 introduced a problem such that a
NULL thread handler could be used during a
rollback operation. This problem is unlikely to be seen in
CREATE TABLE ... LIKE statement
that was waiting for a name lock caused a server crash. When the
statement was killed, the server attempted to release locks that
were not held.
The length of the result from
IFNULL() could be calculated
incorrectly because the sign of the result was not taken into
SELECT 1 REGEX NULL caused an assertion
failure for debug servers.
RENAME while tables were open for
HANDLER statements could
cause a server crash.
mysql-test-run.pl tried to create files in a
directory where it could not be expected to have write
permission. mysqltest created
.reject files in a directory other than the
one where test results go.
DROP USER caused an increase in
For an almost-full
MyISAM table, an insert
that failed could leave the table in a corrupt state.
myisamchk --unpack could corrupt a table that when unpacked has static (fixed-length) row format. (Bug #31277)
CONVERT( failed on invalid input, but processing was
not aborted for the
WHERE clause, leading to
a server crash.
Allocation of an insufficiently large group-by buffer following creation of a temporary table could lead to a server crash. (Bug #31249)
GROUP_CONCAT() could cause a
Server variables could not be set to their current values on Linux platforms. (Bug #31177)
References: See also Bug #6958.
NULL when used in an
BY that was evaluated using
filesort, a server crash could result.
Full-text searches on
ucs2 columns caused a
server crash. (
FULLTEXT indexes on
ucs2 columns cannot be used, but it should be
possible to perform
IN BOOLEAN MODE searches
ucs2 columns without a crash.)
An assertion designed to detect a bug in the
ROLLUP implementation would incorrectly be
triggered when used in a subquery context with noncacheable
Selecting spatial types in a
UNION could cause a server crash.
The server crashed in the parser when running out of memory. Memory handling in the parser has been improved to gracefully return an error when out-of-memory conditions occur in the parser. (Bug #31153)
MySQL declares a
UNIQUE key as a
PRIMARY key if it doesn't have
NULL columns and is not a partial key, and
PRIMARY key must alway be the first key.
However, in some cases, a nonfirst key could be reported as
PRIMARY, leading to an assert failure by
InnoDB. This is fixed by correcting the key
GROUP BY NULL WITH ROLLUP could cause a
References: See also Bug #32558.
REGEXP operations could cause a
server crash for character sets such as
Now the arguments are converted to
possible, to permit correct results to be produced if the
resulting strings contain only 8-bit characters.
Internal conversion routines could fail for several multibyte
character sets (
sjis) for empty
strings or during evaluation of
(Bug #31069, Bug #31070)
Many nested subqueries in a single query could led to excessive memory consumption and possibly a crash of the server. (Bug #31048)
MOD() function and the
% operator crashed the server for a divisor
less than 1 with a very long fractional part.
On Windows, the
implementation was incorrect.
A character set introducer followed by a hexadecimal or bit-value literal did not check its argument and could return an ill-formed result for invalid input. (Bug #30986)
CHAR( did not check its
argument and could return an ill-formed result for invalid
The result from
CHAR() did not add a leading 0x00 byte for input
strings with an odd number of bytes.
GeomFromText() function could
cause a server crash if the first argument was
NULL or the empty string.
MAKEDATE() incorrectly moved year
values in the 100 to 200 range into the 1970 to 2069 range.
(This is legitimate for 00 to 99, but three-digit years should
be used unchanged.)
When invoked with constant arguments,
STR_TO_DATE() could use a cached
value for the format string and return incorrect results.
',' rather than an empty string when the
argument column contained only empty strings.
MEMORY tables, lookups for
NULL values in
indexes could return incorrect results.
nonconstant arguments triggered an assertion failure.
Nonconstant arguments are no longer permitted.
For a spatial column with a regular
SPATIAL) index, queries failed if the
optimizer tried to use the index.
Values for the
incorrectly were treated as values for the
The optimizer incorrectly optimized conditions out of the
WHERE clause in some queries involving
subqueries and indexed columns.
Improper calculation of
expression results could lead to value truncation.
On Windows, the
implementation was incorrect. One symptom was that invalidating
the query cache could cause a server crash.
transactional and nontransactional tables caused an assertion
Under some circumstances,
CREATE TABLE ...
SELECT could crash the server or incorrectly report
that the table row size was too large.
The optimizer could ignore
ORDER BY in cases
when the result set is ordered by
resulting in rows being returned in incorrect order.
MyISAM tables could not exceed 4294967295
(232 − 1) rows on Windows.
mysql-test-run.pl could not run
DELETE statements that remove
rows based on an index read could fail to remove all matching
GROUP BY on an expression of the form
caused a server
crash due to incorrect calculation of number of decimals.
The options available to the
TABLE statement were also permitted in
OPTIMIZE TABLE and
ANALYZE TABLE statements, but
caused corruption during their execution. These options were
never supported for these statements, and an error is now raised
if you try to apply these options to these statements.
When expanding a
* in a
NATURAL join, the
check for table access for both tables in the join was done
using only the grant information of the first table.
When casting a string value to an integer, cases where the input
string contained a decimal point and was long enough to overrun
unsigned long long type were not handled
correctly. The position of the decimal point was not taken into
account which resulted in miscalculated numbers and incorrect
truncation to appropriate SQL data type limits.
Versions of mysqldump from MySQL 4.1 or
higher tried to use
START TRANSACTION WITH CONSISTENT
SNAPSHOT if the
--master-data options were
given, even with servers older than 4.1 that do not support
CREATE ... SELECT ... FROM, where the
resulting table contained indexes, adding
SQL_BUFFER_RESULT to the
SELECT part caused index
corruption in the table.
The optimizer made incorrect assumptions about the value of the
is_member value for user-defined functions,
sometimes resulting in incorrect ordering of UDF results.
euc-kr characters having the
second byte in the ranges
[0x61..0x7A] were rejected.
BLACKHOLE tables caused 100%
CPU use due to locking problems.
Setting certain values on a table using a spatial index could cause the server to crash. (Bug #30286)
Tables with a
GEOMETRY column could be marked
as corrupt if you added a non-
INFORMATION_SCHEMA tables are intended
for internal use, but could be accessed by using
On some 64-bit systems, inserting the largest negative value
BIGINT column resulted in
Under some circumstances, a UDF initialization function could be passed incorrect argument lengths. (Bug #29804)
--without-geometry option for
configure caused server compilation to fail.
configure did not find
on some Linux platforms.
Views were treated as insertable even if some base table columns with no default value were omitted from the view definition. (This is contrary to the condition for insertability that a view must contain all columns in the base table that do not have a default value.) (Bug #29477)
The mysql client program now ignores Unicode byte order mark (BOM) characters at the beginning of input files. Previously, it read them and sent them to the server, resulting in a syntax error.
Presence of a BOM does not cause mysql to
change its default character set. To do that, invoke
mysql with an option such as
For transactional tables, an error during a multiple-table
DELETE statement did not roll
back the statement.
variables were displayed by
VARIABLES but could not be accessed in expressions as
@@log_slow_queries. Also, attempting to set
produced an incorrect
Unknown system variable
message. Now these variables can be accessed in expressions and
attempting to set their values produces an error message that
the variable is read only.
Denormalized double-precision numbers cannot be handled properly by old MIPS processors. For IRIX, this is now handled by enabling a mode to use a software workaround. (Bug #29085)
SHOW VARIABLES did not display
relay_log_info_file system variables.
When doing a
DELETE on a table
that involved a
MERGE tables and the
JOIN referred to the same table, the
operation could fail reporting
ERROR 1030 (HY000): Got
error 134 from storage engine. This was because scans
on the table contents would change because of rows that had
already been deleted.
On Windows, mysql_upgrade created temporary
C:\ and did not clean them up.
Index hints specified in view definitions were ignored when using the view to select from the base table. (Bug #28702)
Views do not have indexes, so index hints do not apply. Use of index hints when selecting from a view is no longer permitted. (Bug #28701)
After changing the SQL mode to a restrictive value that would make already inserted dates in a column be considered invalid, searches returned different results depending on whether the column was indexed. (Bug #28687)
The result from
incorrectly assumed in some contexts to return a single-byte
The parser confused user-defined function (UDF) and stored
function creation for
FUNCTION and required that there be a default database
when creating UDFs, although there is no such requirement.
(Bug #28318, Bug #29816)
The metadata in some
could be incorrect when a temporary table was used to evaluate a
comp_err created files with permissions such that they might be inaccessible during make install operations. (Bug #27789)
The anonymous accounts were not being created during MySQL installation. (Bug #27692)
A race condition between killing a statement and the thread executing the statement could lead to a situation such that the binary log contained an event indicating that the statement was killed, whereas the statement actually executed to completion. (Bug #27571)
Some queries using the
NAME_CONST() function failed to
return either a result or an error to the client, causing it to
hang. This was due to the fact that there was no check to insure
that both arguments to this function were constant expressions.
(Bug #27545, Bug #32559)
resolveip failed to produce correct results for host names that begin with a digit. (Bug #27427)
mysqld sometimes miscalculated the number of
digits required when storing a floating-point number in a
CHAR column. This caused the
value to be truncated, or (when using a debug build) caused the
server to crash.
References: See also Bug #12860.
mysqlcheck -A -r did not correctly identify all tables that needed repairing. (Bug #25347)
If the expected precision of an arithmetic expression exceeded the maximum precision supported by MySQL, the precision of the result was reduced by an unpredictable or arbitrary amount, rather than to the maximum precision. In some cases, exceeding the maximum supported precision could also lead to a crash of the server. (Bug #24907)
For Windows Vista, MySQLInstanceConfig.exe did not include a proper manifest enabling it to run with administrative privileges. (Bug #22563)
References: See also Bug #24732.
mysqldumpslow returned a confusing error message when no configuration file was found. (Bug #20455)
readline library has been updated to
version 5.2. This addresses issues in the
mysql client where history and editing within
the client failed to work as expected.
Clients were ignoring the TCP/IP port number specified as the
default port using the
Zero-padding of exponent values was not the same across platforms. (Bug #12860)
Values of types
ZEROFILL, were not zero-filled when converted to a
character representation in the C prepared statement API.
mysql stripped comments from statements sent
to the server. Now the
--skip-comments option can be
used to control whether to retain or strip comments. The default
(Bug #11230, Bug #26215)
If no automatically generated value is successfully inserted,
Several buffer-size system variables were either being handled incorrectly for large values (for settings larger than 4GB, they were truncated to values less than 4GB without a warning), or were limited unnecessarily to 4GB even on 64-bit systems. The following changes were made:
larger than 4GB are permitted on 64-bit platforms (except
Windows, for which large values are truncated to 4GB with a
DISABLE KEYS and
KEYS on a nonempty table would cause the size of the
index file for the table to grow considerable. This was because
DISABLE KEYS operation would only mark
the existing index, without deleting the index blocks. The
ENABLE KEYS operation would re-create the
index, adding new blocks, while the previous index blocks would
remain. Existing indexes are now dropped and recreated when the
ENABLE KEYS statement is executed.