MySQL Forums
Forum List  »  Announcements

MySQL 5.1.24-rc has been released
Posted by: Kent Boortz
Date: April 16, 2008 08:56AM

Dear MySQL users,

We are proud to present to you the MySQL Server 5.1.24-rc release,
a new "release candidate" version of the popular open source database.

Bear in mind that this is still a "candidate" release, and as with any
other pre-production release, caution should be taken when installing on
production level systems or systems with critical data. For production
level systems using 5.0, we would like to direct your attention to the
product description of MySQL Enterprise at:

The MySQL 5.1.24-rc release is now available in source and binary form
for a number of platforms from our download pages at

and mirror sites. Note that not all mirror sites may be up to date at
this point in time, so if you can't find this version on some mirror,
please try again later or choose another download site.

Please also note that some of our mirrors are currently experiencing
problems that may result in serving corrupted files. We are working with
the mirror maintainers to resolve this.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches etc.:

The description of the changes from version 5.1.23-rc to this 5.1.24-rc
is some 1,800 lines long, that is about 96 kB. As some mail systems are
bound to truncate long mail at 64 kB, I split the announcement into two
parts - this is part 1 only.

The following section lists the (first part of the) changes from version
to version in the MySQL source code since the latest released version of
MySQL 5.1, the MySQL 5.1.23-rc release. It can also be viewed online at


Kent Boortz
The MySQL build team at Sun Microsystems


Functionality added or changed:

* Please note that the Federated engine is not built into the MySQL
5.1.24 RC release binaries, but is scheduled to return in the next
release, which will be MySQL 5.1.25. The reasons for Federated's
omission in 5.1.24 RC includes various quality and timing issues
that unfortunately could not be avoided, and we apologize for any
inconvenience this has caused.

* Windows Installer: Important Change: The data directory now defaults
to the Windows Common App Data Folder (on Windows XP, this is
...\All Users\Application Data; on Vista, it is ProgramData).

* Cluster API: Important Change: Because
NDB_LE_MemoryUsage.page_size_kb shows memory page sizes in
bytes rather than kilobytes, it has been renamed to
page_size_bytes. The name page_size_kb is now deprecated and
thus subject to removal in a future release, although it
currently remains supported for reasons of backwards
compatibility. See The Ndb_logevent_type Type
for more information about NDB_LE_MemoryUsage.

* 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.

* 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
+ When the server is using --binlog-format=STATEMENT, these
statements produce a warning.

See also Bug#34732:

* The ndbd and ndb_mgmd manpages have been reclassified from
volume 1 to volume 8. (Bug#34642:

* For binary .tar.gz packages, mysqld and other binaries now are
compiled with debugging symbols included to enable easier use
with a debugger. (Bug#33252:

* 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 that 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.

* mysqltest now has mkdir and rmdir commands for creating and
removing directories. (Bug#31004:

* The server uses less memory when loading privileges containing
table grants. (Patch provided by Google.)

* Added the Uptime_since_flush_status status variable, which
indicates the number of seconds since the most recent FLUSH
STATUS statement. (From Jeremy Cole)

* Potential memory leaks in SHOW PROFILE were eliminated.

* SHOW OPEN TABLES now supports FROM and LIKE clauses.

* 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().

* 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, "Adaptive Hash Indexes."


Errata in this release:

The Configuration Wizard for Windows has a few known problems
which will be fixed in the following release:

* The Configuration Wizard may report an error when changing
the root password; however, the password will be changed. The
warning pop-up may be hidden behind the active window.

* The Configuration Wizard may report [Internal error 2739]. A
workaround for this failure is described here:


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
now disallowed. This is now also true of these options when
used with partitioned tables and individual partitions of such
tables. (Bug#32167:

* Partitioning: Incompatible Change: The following statements
did not function correctly with corrupted or crashed tables
and have been removed:


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. In addition, it remains possible to use
mysqlcheck on partitioned tables and myisamchk on partitioned
MyISAM tables. (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:

* 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.

* Disk Data: Important Change: It is no longer possible on
32-bit systems to issue statements appearing to create Disk
Data log files or data files greater than 4 GB in size.
(Trying to create log files or data files larger than 4 GB on
32-bit systems led to unrecoverable data node failures; such
statements now fail with NDB error 1515.)

* 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
deprecated. (Bug#33834:

* Important Change: InnoDB free space information is now shown
in the Data_free column of SHOW TABLE STATUS and in the
This regression was introduced by

* 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.

* 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.

* Partitioning: MySQL Cluster: When partition pruning on an NDB
table resulted in an ordered index scan spanning only one
partition, any descending flag for the scan was wrongly
discarded, causing ORDER BY DESC to be treated as ORDER BY
ASC, MAX() to be handled incorrectly, and similar problems.

* MySQL Cluster: Upgrades of a cluster using while a DataMemory
setting in excess of 16 GB caused data nodes to fail.

* MySQL Cluster: Performing many SQL statements on NDB tables
while in AUTOCOMMIT mode caused a memory leak in mysqld.

* MySQL Cluster: In certain rare circumstances, a race condition
could occur between an aborted insert and a delete leading a
data node crash. (Bug#34260:

* MySQL Cluster: Multi-table updates using ordered indexes
during handling of node failures could cause other data nodes
to fail. (Bug#34216:

* MySQL Cluster: When configured with NDB support, MySQL failed
to compile using gcc 4.3 on 64bit FreeBSD systems.

* MySQL Cluster: The failure of a DDL statement could sometimes
lead to node failures when attempting to execute subsequent
DDL statements. (Bug#34160:

* MySQL Cluster: Extremely long SELECT statements (where the
text of the statement was in excess of 50000 characters)
against NDB tables returned empty results.

* MySQL Cluster: When configured with NDB support, MySQL failed
to compile on 64bit FreeBSD systems.
See also Bug#32175:

* MySQL Cluster: High numbers of insert operations, delete
operations, or both could cause NDB error 899 (Rowid already
allocated) to occur unnecessarily.

* MySQL Cluster: A periodic failure to flush the send buffer by
the NDB TCP transporter could cause an unnecessary delay of 10
ms between operations.

* MySQL Cluster: A race condition could occur (very rarely) when
the release of a GCI was followed by a data node failure.

* MySQL Cluster: Some tuple scans caused the wrong memory page
to be accessed, leading to invalid results. This issue could
affect both in-memory and Disk Data tables.

* MySQL Cluster: Statements executing multiple inserts performed
poorly on NDB tables having AUTO_INCREMENT columns.

* 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: The ndb_waiter utility polled ndb_mgmd
excessively when obtaining the status of cluster data nodes.
See also Bug#32023:

* MySQL Cluster: Transaction atomicity was sometimes not
preserved between reads and inserts under high loads.

* MySQL Cluster: Numerous NDBCLUSTER test failures occurred in
builds compiled using icc on IA64 platforms.

* MySQL Cluster: The server failed to reject properly the
creation of an NDB table having an unindexed AUTO_INCREMENT
column. (Bug#30417:

* MySQL Cluster: Having tables with a great many columns could
cause Cluster backups to fail.

concurrently with or following a TRUNCATE statement on an NDB
table failed with NDB error 4350 Transaction already aborted.

* MySQL Cluster: The Cluster backup process could not detect
when there was no more disk space and instead continued to run
until killed manually. Now the backup fails with an
appropriate error when disk space is exhausted.

* MySQL Cluster: It was possible in config.ini to define cluster
nodes having node IDs greater than the maximum allowed value.

* MySQL Cluster: CREATE TABLE and ALTER TABLE statements using
ENGINE=NDB or ENGINE=NDBCLUSTER caused mysqld to fail on
Solaris 10 for x86 platforms.

* 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.

* 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.

* 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: 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: 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:

* Replication: INSERT_ID was not written to the binary log for
inserts into BLACKHOLE tables.

* 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.
See also Bug#31168:

* Replication: When the Windows version of mysqlbinlog read 4.1
binlogs containing LOAD DATA INFILE statements, it output
backslashes as path separators, causing problems for client
programs expecting forward slashes. In such cases, it now
converts \\ to / in directory paths.

* 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.
This regression was introduced by

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.

* Replication: An extraneous ROLLBACK statement was written to
the binary log by a connection that did not use any
transactional tables. (Bug#33329:

* Replication: mysqlbinlog failed to release all of its memory
after terminating abnormally.

* 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).
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.

* 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.

* Replication: SQL statements containing comments using --
syntax were not replayable by mysqlbinlog, even though such
statements replicated correctly.

* Replication: When using row-based replication from a master
running MySQL 5.1.21 or earlier to a slave running 5.1.22 or
later, updates of integer columns failed on the slave with
Error in Unknown event: row application failed.
This regression was introduced by

* 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.

* 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.

* 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.

* 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: Slaves running MySQL 5.1.18 and later could not
read binary logs from older versions of the server.
This regression was introduced by

* Replication: MASTER_POS_WAIT() did not return NULL when the
server was not a slave.

* Replication: Network timeouts between the master and the slave
could result in corruption of the relay log.

* 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

+ 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: START SLAVE UNTIL MASTER_LOG_POS=position issued
on a slave that was using --log-slave-updates and that was
involved in circular replication would cause the slave to run
and stop one event later than that specified by the value of
position. (Bug#13861:

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.

* Cluster Replication: Disk Data: Statements violating unique
keys on Disk Data tables (such as attempting to insert NULL
into a NOT NULL column) could cause data nodes to fail. When
the statement was executed from the binlog, this could also
result in failure of the slave cluster.

* Disk Data: Updating in-memory columns of one or more rows of
Disk Data table, followed by deletion of these rows and
re-insertion of them, caused data node failures.

* Cluster Replication: Setting --replicate-ignore-db=mysql
caused the mysql.ndb_apply_status table not to be replicated,
breaking Cluster Replication.

* Cluster API: When reading a BIT(64) value using
NdbOperation:getValue(), 12 bytes were written to the buffer
rather than the expected 8 bytes.

* Binary log purging caused an assertion failure if a binary log
file could not be deleted (such as when the name actually
referred to a directory).

* Manually replacing a binary log file with a directory having
the same name caused an error that was not handled correctly.

* Using LOAD DATA INFILE with a view could crash the server.

could cause a server crash.
See also Bug#35108:

* For a TERMPORARY table, DELETE with no WHERE clause could fail
when preceded by DELETE statements with a WHERE clause.

* If the server crashes with an InnoDB error due to
unavailability of undo slots and the used slots are not used
during rollback, the error could persist when the server is
restarted. (Bug#35352:

* In some cases, when too many clients tried to connect to the
server, the proper SQLSTATE code was not returned.

* For InnoDB tables, ALTER TABLE DROP failed if the name of the
column to be dropped began with "foreign".

* Queries could return different results depending on whether
ORDER BY columns were indexed.

* 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:

caused the server to crash if the table referenced by a
foreign key had been dropped. This issue was observed on
Windows platforms only.
See also Bug#35406:

* Non-connection threads were being counted in the value of the
Max_used_connections status variable.

* 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.
This regression was introduced by

* 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.

* 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.

* 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.

* If fsync() returned ENOLCK, InnoDB could treat this as fatal
and cause abnormal server termination. InnoDB now retries the
operation. (Bug#34823:

* 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.

* Using NAME_CONST() with a negative number and an aggregate
function caused MySQL to crash. This could also have a
negative impact on replication.

* A memory-handling error associated with use of GROUP_CONCAT()
in subqueries could result in a server crash.

* 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 col_name < N failed
to return rows where the value of col_name is N - 1.

* Executing a TRUNCATE statement on a table having both a
foreign key reference and a DELETE trigger crashed the server.

* 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:

* Creating a view inside a stored procedure could lead to a
crash of the MySQL Server.

* CAST(AVG(arg) AS DECIMAL) produced incorrect results for
non-DECIMAL arguments.

* Executing an ALTER VIEW statement on a table crashed the
server. (Bug#34337:

* InnoDB could crash if overflow occurred for an AUTO_INCREMENT
column. (Bug#34335:

* For InnoDB, exporting and importing a table could corrupt
TINYBLOB columns, and a subsequent ALTER TABLE could corrupt
TINYTEXT columns as well.

* DEFAULT 0 was not allowed for the YEAR data type.

* Under some conditions, a SET GLOBAL innodb_commit_concurrency
or SET GLOBAL innodb_autoextend_increment statement could
fail. (Bug#34223:

* Use of stored functions in the WHERE clause for SHOW OPEN
TABLES caused a server crash.

* 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.

* 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.)

* A query using WHERE (column1='string1' AND column2=constant1)
OR (column1='string2' AND column2=constant2), where 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=constant1
OR column2=constant2. (Bug#33833:

* 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.

* Some queries using a combination of IN, CONCAT(), and an
implicit type conversion could return an incorrect result.

* 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.

* 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.

* 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.

* 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.

* Dropping a function after dropping the function's creator
could cause the server to crash.

* 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.
See also Bug#31177:

* For InnoDB tables, there was a race condition involving the
data dictionary and repartitioning.

* 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

* Using Control-R in the mysql client caused it to crash.

* Granting the UPDATE privilege on one column of a view caused
the server to crash. (Bug#33201:

* For DECIMAL columns used with the ROUND(X,D) or TRUNCATE(X,D)
function with a non-constant value of D, adding an ORDER BY
for the function result produced misordered output.
See also Bug#33402:,

* 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:

* 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.

* 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.

* For DISTINCT queries, 4.0 and 4.1 stopped reading joined
tables as soon as the first matching row was found. However,
this optimzation 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.

* Repeated creation and deletion of views within prepared
statements could eventually crash the server.
See also Bug#34587:

* In some cases where setting a system variable failed, no error
was sent to the client, causing the client to hang.

* 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.

statements incorrectly required the SUPER privilege rather
than the PROCESS privilege.

* 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.

* 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.
See also Bug#21505:

* 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:

* 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 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:

* 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.

* On Windows, mysqltest_embedded.exe did not properly execute
the send command. (Bug#32044:

* A variable named read_only could be declared even though that
is a reserved word. (Bug#31947:

* On Windows, the build process failed with four parallel build
threads. (Bug#31929:

* Queries testing numeric constants containing leading zeroes
against ZEROFILL columns were not evaluated correctly.

* If an error occurred during file creation, the server
sometimes did not remove the file, resulting in an unused file
in the filesystem. (Bug#31781:

* The mysqld crash handler failed on Windows.

* The server returned the error message Out of memory; restart
server and try again when the actual problem was that the sort
buffer was too small. Now an appropriate error message is
returned in such cases.

* A table having an index that included a BLOB or TEXT column,
and that was originally created with a MySQL server using
version 4.1 or earlier, could not be opened by a 5.1 or later
server. (Bug#31331:

* The -, *, and / operators and the functions POW() and EXP()
could misbehave when used with floating-point numbers.
Previously they might return +INF, -INF, or NaN in cases of
numeric overflow (including that caused by division by zero)
or when invalid arguments were used. Now NULL is returned in
all such cases. (Bug#31236:

* The mysql_change_user() C API function caused global Com_xxx
status variable values to be incorrect.

* When sorting privilege table rows, the server treated escaped
wildcard characters (\% and \_) the same as unescaped wildcard
characters (% and _), resulting in incorrect row ordering.

* An assertion failure occurred for queries containing two
subqueries if both subqueries were evaluated using a semi-join
strategy. (Bug#31040:

* ROUND(X,D) or TRUNCATE(X,D) for non-constant values of D could
crash the server if these functions were used in an ORDER BY
that was resolved using filesort.

* Resetting the query cache by issuing a SET GLOBAL
query_cache_size=0 statement caused the server to crash if it
concurrently was saving a new result set to the query cache.

* Manifest problems prevented MySQLInstanceConfig.exe from
running on Windows Vista.

* If an alias was used to refer to the value returned by a
stored function within a subselect, the outer select
recognized the alias but failed to retrieve the value assigned
to it in the subselect.

* Replication of LOAD DATA INFILE could fail when
read_buffer_size was larger than max_allowed_packet.

* The Table_locks_waited waited variable was not incremented in
the cases that a lock had to be waited for but the waiting
thread was killed or the request was aborted.

* The Com_create_function status variable was not incremented
properly. (Bug#30252:

* mysqld displayed the --enable-pstack option in its help
message even if MySQL was configured without --with-pstack.

* The mysql_config command would output CFLAGS values that were
incompatible with C++ for the HP-UX platform.

* Replication crashed with the NDB storage engine when mysqld
was started with --character-set-server=ucs2.

* 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.)

* myisamchk always reported the character set for a table as
latin1_swedish_ci (8) regardless of the table' actual
character set. (Bug#29182:

* InnoDB could return an incorrect rows-updated value for UPDATE
statements. (Bug#29157:

* The MySQL preferences pane did not work to start or stop MySQL
on Mac OS X 10.5 (Leopard).

* For upgrading to a new major version using RPM packages (such
as 4.1 to 5.0), if the installation procedure found an
existing MySQL server running, it could fail to shut down the
old server, but also erroneously removed the server's socket
file. Now the procedure checks for an existing server package
from a different vendor or major MySQL version. In such case,
it refuses to install the server and recommends how to safely
remove the old packages before installing the new ones.

* mysqlhotcopy silently skipped databases with names consisting
of two alphanumeric characters.

* No information was written to the general query log for the
commands. (These occur when a client invokes the
mysql_stmt_close(), mysql_stmt_reset() and
mysql_stmt_send_long_data() C API functions.)

* Previously, the parser accepted the ODBC { OJ ... LEFT OUTER
JOIN ...} syntax for writing left outer joins. The parser now
allows { OJ ... } to be used to write other types of joins,
such as INNER JOIN or RIGHT OUTER JOIN. This helps with
compatibility with some third-party applications, but is not
official ODBC syntax. (Bug#28317:

* The SQL parser did not accept an empty UNION=() clause. This
meant that, when there were no underlying tables specified for
a MERGE table, SHOW CREATE TABLE and mysqldump both output
statements that could not be executed.
Now it is possible to execute a CREATE TABLE or ALTER TABLE
statement with an empty UNION=() clause. However, SHOW CREATE
TABLE and mysqldump do not output the UNION=() clause if there
are no underlying tables specified for a MERGE table. This
also means it is now possible to remove the underlying tables
for a MERGE table using ALTER TABLE ... UNION=().

* The utf8_general_ci collation incorrectly did not sort "U+00DF
SHARP S" equal to 's'.

* It was possible to exhaust memory by repeatedly running
index_merge queries and never performing any FLUSH TABLES
statements. (Bug#27732:

* When utf8 was set as the connection character set, using
SPACE() with a non-Unicode column produced an error.
See also Bug#23637:

* The parser rules for the SHOW PROFILE statement were revised
to work with older versions of bison.

* resolveip failed to produce correct results for hostnames that
begin with a digit. (Bug#27427:

* In ORDER BY clauses, mixing aggregate functions and
non-grouping columns is not allowed if the ONLY_FULL_GROUP_BY
SQL mode is enabled. However, in some cases, no error was
thrown because of insufficient checking.

* Memory corruption, a crash of the MySQL server, or both, could
take place if a low-level I/O error occurred while an ARCHIVE
table was being opened.

* SHOW PROFILE hung if executed before enabling the @@profiling
session variable. (Bug#26938:

* config-win.h unconditionally defined bool as BOOL, causing
problems on systems where bool is 1 byte and BOOL is 4 bytes.

* On Windows, for distributions built with debugging support,
mysql could crash if the user typed Control-C.

* When symbolic links were disabled, either with a server
startup option or by enabling the NO_DIR_IN_CREATE SQL mode,
CREATE TABLE silently ignored the DATA DIRECTORY and INDEX
DIRECTORY table options. Now the server issues a warning if
symbolic links are disabled when these table options are used.

* Attempting to create an index with a prefix on a DECIMAL
column appeared to succeed with an inaccurate warning message.
Now, this action fails with the error Incorrect prefix key;
the used key part isn't a string, the used length is longer
than the key part, or the storage engine doesn't support
unique prefix keys. (Bug#25426:

* mysqlcheck -A -r did not correctly identify all tables that
needed repairing. (Bug#25347:

* The Qcache_free_blocks status variable did not display a value
of 0 if the query cache was disabled.

* The client library had no way to return an error if no
connection had been established. This caused problems such as
mysql_library_init() failing silently if no errmsg.sys file
was available. (Bug#25097:

* On Mac OS X, the StartupItem for MySQL did not work.

* mysql did not use its completion table. Also, the table
contained few entries.

* Logging of statements to log tables was incorrect for
statements that contained utf8-incompatible binary strings.
Incompatible sequences are hex-encoded now.

* The MySQL header files contained some duplicate macro
definitions that could cause compilation problems.

* SHOW COLUMNS on a TEMPOARY table caused locking issues.

* For distributions compiled with the bundled libedit library,
there were difficulties using the mysql client to enter input
for non-ASCII or multi-byte characters.

* perror reported incomplete or inaccurate information.

* InnoDB exhibited thread thrashing with more than 50 concurrent
connections under an update-intensive workload.

* After stopping and starting the event scheduler, disabled
events could remain in the execution queue.

* The server produced a confusing error message when attempting
to open a table that required a storage engine that was not
loaded. (Bug#22708:

* For views or stored programs created with an invalid DEFINER
value, the error message was confusing (did not tie the
problem to the DEFINER clause) and has been improved.

* Warnings for deprecated syntax constructs used in stored
routines make sense to report only when the routine is being
created, but they were also being reported when the routine
was parsed for loading into the execution cache. Now they are
reported only at routine creation time.

* Renaming a column that appeared in a foreign key definition
did not update that definition with the new column name. This
occurred with both referenced and referencing tables.

* On Mac OS X, mysqld did not react to Ctrl-C when run under
gdb, even when run with the --gdb option.

* CREATE ... SELECT did not always set DEFAULT column values in
the new table. (Bug#21380:

* mysql_config output did not include -lmygcc on some platforms
when it was needed. (Bug#21158:

* The BENCHMARK() function, invoked with more than 2147483648
iterations (the size of a signed 32-bit integer), terminated
prematurely. (Bug#20752:

* MySQLInstanceConfig.exe could lose the innodb_data_home_dir
setting when reconfiguring an instance.

* DROP DATABASE did not drop orphaned FOREIGN KEY constraints.

* CREATE TABLE allowed 0 as the default value for a TIMESTAMP
column when the server was running in NO_ZERO_DATE mode.

* A SET column whose definition specified 64 elements could not
be updated using integer values.

* If a SELECT calls a stored function in a transaction, and a
statement within the function fails, that statement should
roll back. Furthermore, if ROLLBACK is executed after that,
the entire transaction should be rolled back. Before this fix,
the failed statement did not roll back when it failed (even
though it might ultimately get rolled back by a ROLLBACK later
that rolls back the entire transaction).
See also Bug#34655:

* The parser incorrectly allowed SQLSTATE '00000' to be
specified for a condition handler. (This is incorrect because
the condition must be a failure condition and '00000'
indicates success.) (Bug#8759:

Kent Boortz, Release Staff Engineer
Oracle, the MySQL team,

Options: ReplyQuote

Written By
MySQL 5.1.24-rc has been released
April 16, 2008 08:56AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.