MySQL 6.0.11-alpha リリース
投稿日時 2009-5-25 15:49:08 | トピック： MySQL 6.0
| MySQL 6.0.11-alpha がリリースされました。
これは、MySQL 6.0 シリーズ（現在アルファー版）の最新版です。
ダウンロードはこちらから：
http://dev.mysql.com/downloads/mysql/6.0.html
今回も数多くの修正がなされています。今回もレプリケーションに関する修正が目立ちますが、それ以外でおもしろそうなものとしては、mysqlbackup コマンドの追加が挙げられます。
mysqlbackup コマンドは、BACKUP DATABASE 文で作成したバックアップファイルの情報を表示するもののようです。
また、今後のMySQL 6.0シリーズのリリース予定について、以下のアナウンスがなされています。
「9月までのマイルストンとしては、6.0の大部分の機能を実装したいと考えている。もっと詳細な情報は 6月末までに公表する。マイルストンに乗らなかった機能（オンラインバックアップ、falcon、コネクションプーリング、4 byte utf)も安定版リリースまでには実装する」
----------
以下チェンジログ(6.0.11-alpha)：
■機能の追加と変更(6.0.11-alpha)：
* Incompatible Change: The optimizer_switch system variable
controls optimizations that can be switched on and off. The
syntax for flags in its value has changed from 'no_opt_name'
to 'opt_name={on|off|default}'. For information about the new
syntax, see Section 7.2.22, "Using optimizer_switch to Control
the Optimizer."
* Replication: The global server variables sync_master_info and
sync_relay_log_info are introduced for use on replication
slaves to control synchronization of, respectively, the
master.info and relay.info files.
In each case, setting the variable to a nonzero integer value
N causes the slave to synchonize the corresponding file to
disk after every N events. Setting its value to 0 allows the
operation system to handle syncronization of the file instead.
The actions of these variables, when enabled, are analogous to
how the sync_binlog variable works with regard to binary logs
on a replication master.
These variables can also be set in my.cnf, or by using the
server options --sync-master-info and --sync-relay-log-info
respectively.
An additional system variable relay_log_recovery is also now
available. When enabled, this variable causes a replication
slave to discard relay log files obtained from the replication
master following a crash.
This variable can also be set in my.cnf, or by using the
--relay-log-recovery server option.
This fix improves and expands upon one made in MySQL 6.0.10
which introduced the sync_relay_log variable. For more
information about all of the server system variables
introduced by these fixes, see Section 16.1.3.3, "Replication
Slave Options and Variables."
(Bug#31665: http://bugs.mysql.com/31665,
Bug#35542: http://bugs.mysql.com/35542,
Bug#40337: http://bugs.mysql.com/40337)
* mysql-test-run.pl now supports an --experimental=file_name
option. It enables you to specify a file that contains a list
of test cases that should be displayed with the [ exp-fail ]
code rather than [ fail ] if they fail.
(Bug#42888: http://bugs.mysql.com/42888)
* The MD5 algorithm now uses the Xfree implementation.
(Bug#42434: http://bugs.mysql.com/42434)
* The RESTORE statement now has a SKIP_GAP_EVENT option that
causes the restore operation not to write the gap event to the
binary log that causes any replication slaves to stop
replication. This is useful when RESTORE is run on a master
server and the backup image does not contain databases that
are replicated to the slaves.
(Bug#39780: http://bugs.mysql.com/39780)
* Previously, the --secure-file-priv option and secure_file_priv
system variable, if set to a directory, limited BACKUP
DATABASE and RESTORE operations to files in the given
directory. Now the --secure-backup-file-priv option and
secure_backup_file_priv system variable apply instead.
(Bug#39581: http://bugs.mysql.com/39581)
* The query cache now checks whether a SELECT statement begins
with SQL_NO_CACHE to determine whether it can skip checking
for the query result in the query cache. This is not supported
when SQL_NO_CACHE occurs within a comment.
(Bug#37416: http://bugs.mysql.com/37416)
* A new program, mysqlbackup, displays information from backups
created with the BACKUP DATABASE statement.
* MySQL now implements the SQL standard SIGNAL and RESIGNAL
statements. See Section 12.8.8, "SIGNAL and RESIGNAL."
■バグ修正(6.0.11-alpha)：
* Incompatible Change: For system variables that take values of
ON or OFF, OF was accepted as a legal variable. Now system
variables that take "enumeration" values must be assigned the
full value. This affects some other variables that previously
could be assigned using unambiguous prefixes of allowable
values, such as tx_isolation.
(Bug#34828: http://bugs.mysql.com/34828)
* Incompatible Change: If a data definition language (DDL)
statement occurred for a table that was being used by another
session in an active transaction, statements could be written
to the binary log in the wrong order. For example, this could
happen if DROP TABLE occurred for a table being used in a
transaction. This is now prevented by deferring release of
metadata locks on tables used within a transaction until the
transaction ends.
This bug fix results in some incompatibilities with previous
versions:
+ A table that is being used by a transaction within one
session cannot be used in DDL statements by other
sessions until the transaction ends.
+ FLUSH TABLES WITH READ LOCK blocks for active
transactions that hold metadata locks until those
transactions end. The same is true for attempts to set
the global value of the read_only system variable.
(Bug#989: http://bugs.mysql.com/989)
* Important Change: Replication: CHANGE MASTER TO ...
MASTER_HOST='' --- explicitly setting MASTER_HOST equal to an
empty string --- created a master.info file with an empty host
field. This led to a The server is not configured as slave
error when attempting to execute a START SLAVE statement. Now,
if MASTER_HOST is set to an empty string, the CHANGE MASTER TO
statement fails with an error.
(Bug#28796: http://bugs.mysql.com/28796)
* Replication: Important Note: Binary logging with
--binlog_format=ROW failed when a change to be logged included
more than 251 columns. This issue was not known to occur with
mixed-format or statement-based logging.
(Bug#42977: http://bugs.mysql.com/42977)
See also Bug#42914: http://bugs.mysql.com/42914.
* Replication: The SHOW SLAVE STATUS connection thread competed
with the slave SQL thread for use of the error message buffer.
As a result, the connection thread sometimes received
incomplete messages. This issue was uncovered with valgrind
when message strings were passed without NULL terminators,
causing the error Conditional jump or move depends on
uninitialised value(s).
(Bug#43076: http://bugs.mysql.com/43076)
* Replication: This fix handles 2 issues encountered on
replication slaves during startup:
1. A failure while allocating the master info structure
caused the slave to crash.
2. A failure during recovery caused the relay log file not
to be properly initialized which led to a crash on the
slave.
(Bug#43075: http://bugs.mysql.com/43075)
* Replication: Assigning an invalid directory for the
--slave-load-tmpdir caused the replication slave to crash.
(Bug#42861: http://bugs.mysql.com/42861)
* Replication: The mysql.procs_priv system table was not
replicated. (Bug#42217: http://bugs.mysql.com/42217)
* Replication: When --binlog_format was set to STATEMENT, a
statement unsafe for statement-based logging caused an error
or warning to be issued even if sql_log_bin was set to 0.
(Bug#41980: http://bugs.mysql.com/41980)
* Replication: An INSERT DELAYED into a TIMESTAMP column issued
concurrently with a an insert on the same column not using
DELAYED, but applied after the other insert, was logged using
the same timestamp as generated by the other (non-DELAYED)
insert. (Bug#41719: http://bugs.mysql.com/41719)
* Replication: When using MIXED replication format and temporary
tables were created in statement-based mode, but a later
operation in the same session caused a switch to row-based
mode, the temporary tables were not dropped on the slave at
the end of the session.
(Bug#40013: http://bugs.mysql.com/40013)
See also Bug#43046: http://bugs.mysql.com/43046.
This regression was introduced by
Bug#20499: http://bugs.mysql.com/20499.
* Replication: When using the MIXED replication format, UPDATE
and DELETE statements that searched for rows where part of the
key had nullable BIT columns failed. This occurred because
operations that inserted the data were replicated as
statements, but UPDATE and DELETE statements affecting the
same data were replicated using row-based format.
This issue did not occur when using statement-based
replication (only) or row-based replication (only).
(Bug#39753: http://bugs.mysql.com/39753)
See also Bug#39648: http://bugs.mysql.com/39648.
* Replication: The MIXED binary logging format did not switch to
row-based mode for statements containing the LOAD_FILE()
function. (Bug#39701: http://bugs.mysql.com/39701)
* Replication: The server SQL mode in effect when a stored
procedure was created was not retained in the binary log. This
could cause a CREATE PROCEDURE statement that succeeded on the
master to fail on the slave.
This issue was first noticed when a stored procedure was
created when ANSI_QUOTES was in effect on the master, but
could possibly cause failed CREATE PROCEDURE statements and
other problems on the slave when using other server SQL modes
as well. (Bug#39526: http://bugs.mysql.com/39526)
* Replication: If --secure-file-priv was set on the slave, it
was unable to execute LOAD DATA INFILE statements sent from
the master when using mixed-format or statement-based
replication.
As a result of this fix, this security restriction is now
ignored on the slave in such cases; instead the slave checks
whether the files were created and should be read by the slave
in its --slave-load-tmpdir.
(Bug#38174: http://bugs.mysql.com/38174)
* Replication: Server IDs greater than 2147483647 (2^32 - 1)
were represented by negative numbers in the binary log.
(Bug#37313: http://bugs.mysql.com/37313)
* Replication: The value of Slave_IO_running in the output of
SHOW SLAVE STATUS did not distinguish between all 3 possible
states of the slave I/O thread (not running; running but not
connected; connected). Now the value Connecting (rather than
No) is shown when the slave I/O thread is running but the
slave is not connected to a replication master.
The server system variable Slave_running also reflects this
change, and is now consistent with what is shown for
Slave_IO_running. (Bug#30703: http://bugs.mysql.com/30703,
Bug#41613: http://bugs.mysql.com/41613)
* Replication: Queries which were written to the slow query log
on the master were not written to the slow query log on the
slave. (Bug#23300: http://bugs.mysql.com/23300)
* Replication: When the server SQL mode included IGNORE_SPACE,
statement-based replication of LOAD DATA INFILE ... INTO
tbl_name failed because the statement was read incorrectly
from the binary log; a trailing space was omitted, causing the
statement to fail with a syntax error when run on the slave.
(Bug#22504: http://bugs.mysql.com/22504)
See also Bug#43746: http://bugs.mysql.com/43746.
* Replication: When its disk becomes full, a replication slave
may wait while writing the binary log, relay log or MyISAM
tables, continuing after space has been made available. The
error message provided in such cases was not clear about the
frequency with which checking for free space is done (once
every 60 seconds), and how long the server waits after space
has been freed before continuing (also 60 seconds); this
caused users to think that the server had hung.
These issues have been addressed by making the error message
clearer, and dividing it into two separate messages:
1. The error message Disk is full writing 'filename'
(Errcode: error_code). Waiting for someone to free
space... (Expect up to 60 secs delay for server to
continue after freeing disk space) is printed only once.
2. The warning Retry in 60 secs, Message reprinted in 600
secs is printed once every for every 10 times that the
check for free space is made; that is, the check is
performed once each 60 seconds, but the reminder that
space needs to be freed is printed only once every 10
minutes (600 seconds).
(Bug#22082: http://bugs.mysql.com/22082)
* Memory corruption of join buffers could occur when using the
Batched Key Access algorithm with incremental join buffers to
execute join operations for a query over several tables that
selects BLOB values. (Bug#44250: http://bugs.mysql.com/44250)
* The server could crash at startup when initializing plugins
listed in the plugin table.
(Bug#44137: http://bugs.mysql.com/44137)
* A RESTORE operation that restored a MyISAM table using the
native MyISAM restore driver could cause the MyISAM key cache
to be disabled. (Bug#44068: http://bugs.mysql.com/44068)
* In some cases, when the Batched Key Access algorithm is used
with join_cache_level equal to 6, multi-join queries could
return incorrect results.
(Bug#44019: http://bugs.mysql.com/44019)
* valgrind would report errors for the StorageInterface,
StorageHAndler and CmdGen portions of Falcon.
(Bug#43995: http://bugs.mysql.com/43995)
* On 64-bit debug builds, code in safemalloc resulted in errors
due to use of a 32-bit value for 64-bit allocations.
(Bug#43885: http://bugs.mysql.com/43885)
* When performing a high number of concurrent index updates on a
Falcon table, mysqld could crash due to an assertion.
(Bug#43765: http://bugs.mysql.com/43765)
* An attempt by a user who did not have the SUPER privilege to
kill a system thread could cause a server crash.
(Bug#43748: http://bugs.mysql.com/43748)
* On Windows, incorrectly specified link dependencies in
CMakeLists.txt resulted in link errors for mysql_embedded,
mysqltest_embedded, and mysql_client_test_embedded.
(Bug#43715: http://bugs.mysql.com/43715)
* make distcheck failed to properly handle subdirectories of
storage/ndb. (Bug#43614: http://bugs.mysql.com/43614)
* Incorrect use of parser information could lead to acquisition
of incorrect lock types.
(Bug#43568: http://bugs.mysql.com/43568)
* Upgrading MySQL to 6.0.10 from 6.0.9 when using Falcon tables
and the mysql_upgrade tool would cause mysqld to crash during
start up. (Bug#43562: http://bugs.mysql.com/43562)
* Running a SELECT using a range query on FLOAT on a Maria table
could return invalid result sets.
(Bug#43552: http://bugs.mysql.com/43552)
* Running a SELECT using a range query on with <> or < with a
negative values on a Maria table could return invalid result
sets. (Bug#43530: http://bugs.mysql.com/43530)
* Running a SELECT on a multi-range query with a LIMIT clause on
a Maria table could return invalid result sets.
(Bug#43527: http://bugs.mysql.com/43527)
* Executing a LIMIT ... FOR UPDATE statement on a Falcon table
when using transactions with concurrent threads could cause a
crash because the record information cannot be accessed
correctly. (Bug#43488: http://bugs.mysql.com/43488)
* When performing SELECT statements on a Falcon table using an
indexed INTEGER column could return incorrect row matches.
(Bug#43452: http://bugs.mysql.com/43452)
* RESTORE on a case-insensitive server failed if the backup
image contained databases or tables with uppercase names. Now,
RESTORE handles this case by converting the names to lowercase
in the restore catalog, as long as there are no duplicate
names after the conversion.
(Bug#43363: http://bugs.mysql.com/43363)
* Use of USE INDEX hints could cause EXPLAIN EXTENDED to crash.
(Bug#43354: http://bugs.mysql.com/43354)
* BACKUP DATABASE stored incorrect table counts in the backup
image. (Bug#43324: http://bugs.mysql.com/43324)
* Assigning a value to the backupdir system variable resulted in
Valgrind errors. (Bug#43303: http://bugs.mysql.com/43303)
* mysql crashed if a request for the current database name
returned an empty result, such as after the client has
executed a preceding SET sql_select_limit=0 statement.
(Bug#43254: http://bugs.mysql.com/43254)
* If the value of the version_comment system variable was too
long, the mysql client displayed a truncated startup message.
(Bug#43153: http://bugs.mysql.com/43153)
* Compilation failures on Windows Vista using Visual Studio 2008
Professional were corrected.
(Bug#43120: http://bugs.mysql.com/43120)
* Recovering a Falcon table from a failure when the table
contains BLOB columns could cause an assertion failure.
(Bug#43106: http://bugs.mysql.com/43106)
* On 32-bit Windows, mysqld could not use large buffers due to a
2GB user mode address limit.
(Bug#43082: http://bugs.mysql.com/43082)
* mysqld would crash when using Falcon tables during shutdown if
the server was running in embedded mode.
(Bug#43048: http://bugs.mysql.com/43048)
* The MySQL Backup library had incorrect logic and error
reporting for metadata saving.
(Bug#42959: http://bugs.mysql.com/42959)
* Queries of the following form returned an empty result:
SELECT ... WHERE ... (col=col AND col=col) OR ...
(false expression)
(Bug#42957: http://bugs.mysql.com/42957)
* A two-way join query with a GROUP BY or ORDER BY clause could
produce incorrect results when rows of the first table are
accessed by an index compatible with the GROUP BY or ORDER BY
list while the second table is joined using the Batched Key
Access algorithm. (Bug#42955: http://bugs.mysql.com/42955)
* The strings/CHARSET_INFO.txt file was not included in source
distributions. (Bug#42937: http://bugs.mysql.com/42937)
* When running REPAIR on a crashed Falcon table can crash mysqld
if pages have been incorrectly marked dirty, but not locked,
during write. (Bug#42824: http://bugs.mysql.com/42824)
* stderr should be unbuffered, but when the server redirected
stderr to a file, it became buffered.
(Bug#42790: http://bugs.mysql.com/42790)
* The DATA_TYPE column of the INFORMATION_SCHEMA.COLUMNS table
displayed the UNSIGNED attribute for floating-point data
types. (The column should contain only the data type name.)
(Bug#42758: http://bugs.mysql.com/42758)
* Recovery of Falcon tables while there were active transaction
during the crash may fail to recover completely.
(Bug#42743: http://bugs.mysql.com/42743)
* Use of semijoin optimization could cause a server crash.
(Bug#42740: http://bugs.mysql.com/42740)
* When Falcon is populating the INFORMATION_SCHEMA.TABLESPACES
table, an exception can be raised because required result set
has been closed before the resultset has been completed. This
can happen during a BACKUP operation.
(Bug#42725: http://bugs.mysql.com/42725,
Bug#42830: http://bugs.mysql.com/42830)
* Assigning a value to the backupdir system variable resulted in
a memory leak. (Bug#42695: http://bugs.mysql.com/42695)
* Assigning an incorrect value to the backup_progress_log_file
system variable resulted in Valgrind errors.
(Bug#42685: http://bugs.mysql.com/42685)
* When performing SELECT queries on tables containing TIMESTAMP
or DATETIME colums with indexes using a WHERE clause comparing
the field value to NULL using the <= or <> operators, the
wrong information would be returned.
(Bug#42683: http://bugs.mysql.com/42683,
Bug#43623: http://bugs.mysql.com/43623,
Bug#43620: http://bugs.mysql.com/43620,
Bug#42681: http://bugs.mysql.com/42681)
* A dangling pointer in mysys/my_error.c could lead to client
crashes. (Bug#42675: http://bugs.mysql.com/42675)
* mysqldump included views that were excluded with the
--ignore-table option.
(Bug#42635: http://bugs.mysql.com/42635)
* An earlier bug fix resulted in the problem that the InnoDB
plugin could not be used with a server that was compiled with
the built-in InnoDB. To handle this two changes were made:
+ The server now supports an --ignore-builtin-innodb
(http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters
.html#option_mysqld_ignore-builtin-innodb) option that
causes the server to behave as if the built-in InnoDB is
not present. This option causes other InnoDB options not
to be recognized.
+ For the INSTALL PLUGIN statement, the server reads option
(my.cnf) files just as during server startup. This
enables the plugin to pick up any relevant options from
those files. Consequently, a plugin no longer is started
with each option set to its default value.
Because of this change, it is possible to add plugin
options to an option file even before loading a plugin
(if the loose prefix is used). It is also possible to
uninstall a plugin, edit my.cnf, and install the plugin
again. Restarting the plugin this way enables it to the
new option values without a server restart.
Note
InnoDB Plugin versions 1.0.4 and higher will take advantage of
this bug fix. Although the InnoDB Plugin is source code
compatible with multiple MySQL releases, a given binary InnoDB
Plugin can be used only with a specific MySQL release. When
InnoDB Plugin 1.0.4 is released, it is expected to be compiled
for MySQL 5.1.34. For 5.1.33, you can use InnoDB Plugin 1.0.3,
but you must build from source.
(Bug#42610: http://bugs.mysql.com/42610)
This regression was introduced by
Bug#29263: http://bugs.mysql.com/29263.
* With the ONLY_FULL_GROUP_BY SQL mode enabled, some legal
queries failed. (Bug#42567: http://bugs.mysql.com/42567)
* Recovery of a Falcon table with a large number of rows can
cause a failure in the page type written for the internal
FALCON_USER and FALCON_TEMPORARY tablespaces.
(Bug#42560: http://bugs.mysql.com/42560)
* Passing an unknown time zone specification to CONVERT_TZ()
resulted in a memory leak.
(Bug#42502: http://bugs.mysql.com/42502)
* Tables could enter open table cache for a thread without being
properly cleaned up, leading to a server crash.
(Bug#42419: http://bugs.mysql.com/42419)
* Previously, RESTORE would crash if the backup image contained
tables originally stored in a tablespace that no longer
existed at RESTORE time. Now the tablespace is recreated like
it was at BACKUP DATABASE time if it does not exist when
RESTORE is executed. (Bug#42402: http://bugs.mysql.com/42402)
* If the server was started with
--thread_handling=pool-of-threads, the MAX_QUERIES_PER_HOUR
user resource limit. (Bug#42384: http://bugs.mysql.com/42384)
* Recovery of Falcon tables with indexes can fail because the
index page information has not been recorded properly.
(Bug#42344: http://bugs.mysql.com/42344)
* Using a LIKE clause on a Maria table using an index and the
CP1251 collation would return invalid data.
(Bug#42299: http://bugs.mysql.com/42299)
* Running a SELECT using a JOIN on a Maria table could return
invalid result sets. (Bug#42298: http://bugs.mysql.com/42298)
* Running multi-range queries on Maria tables could cause a
crash. (Bug#42297: http://bugs.mysql.com/42297)
* Using a falcon-scavenge-schedule of * * * * * would cause
Falcon to never execute the required threads to operate.
(Bug#42275: http://bugs.mysql.com/42275)
* If the server was started with an option that had a missing or
invalid value, a subsequent error that would cause normally
the server to shut down could cause it to crash instead.
(Bug#42244: http://bugs.mysql.com/42244)
* Using ORDER BY and or LIMIT on Falcon tables could give
inconsistent results for rows that contain NULL columns in the
corresponding ORDER BY clause.
(Bug#42208: http://bugs.mysql.com/42208)
* For InnoDB tables, there was a race condition for ALTER TABLE,
OPTIMIZE TABLE, CREATE INDEX, and DROP INDEX operations when
periodically checking whether table copying can be committed.
(Bug#42152: http://bugs.mysql.com/42152)
* In InnoDB recovery after a server crash, table lookup could
fail and corrupt the data dictionary cache.
(Bug#42075: http://bugs.mysql.com/42075)
* mysqldumpslow parsed the --debug and --verbose options
incorrectly. (Bug#42027: http://bugs.mysql.com/42027)
* BACKUP DATABASE and RESTORE did not implement backup and
restore of privileges for stored procedures and stored
functions. (Bug#41979: http://bugs.mysql.com/41979)
* Recovering a Falcon table that uses BLOB columns could cause
unbounded tablespace growth before recovery completes.
(Bug#41840: http://bugs.mysql.com/41840)
* Recovery of Falcon tables could fail with an indicating that a
wrong page type was identified in the Falcon serial log.
(Bug#41837: http://bugs.mysql.com/41837,
Bug#42745: http://bugs.mysql.com/42745,
Bug#44114: http://bugs.mysql.com/44114)
* RESTORE crashed for Falcon tables.
(Bug#41722: http://bugs.mysql.com/41722)
* With more than two arguments, LEAST(), GREATEST(), and CASE
could unnecessarily return Illegal mix of collations errors.
(Bug#41627: http://bugs.mysql.com/41627)
* Queries that used the loose index scan access method could
return no rows. (Bug#41610: http://bugs.mysql.com/41610)
* RESTORE failed if it tried to restore a privilege for a
non-existent object. (Bug#41578: http://bugs.mysql.com/41578)
* In InnoDB recovery after a server crash, rollback of a
transaction that updated a column from NULL to NULL could
cause another crash. (Bug#41571: http://bugs.mysql.com/41571)
* The mysql client could misinterpret its input if a line was
longer than an internal buffer.
(Bug#41486: http://bugs.mysql.com/41486)
* The error message for a too-long column comment was Unknown
error rather than a more appropriate message.
(Bug#41465: http://bugs.mysql.com/41465)
* The Falcon CycleManager has been updated, which addresses a
number of issues when examining records in various transaction
states and their visisbility/isolation in relation to other
threads. (Bug#41391: http://bugs.mysql.com/41391,
Bug#41478: http://bugs.mysql.com/41478,
Bug#41742: http://bugs.mysql.com/41742,
Bug#41850: http://bugs.mysql.com/41850,
Bug#42459: http://bugs.mysql.com/42459,
Bug#41661: http://bugs.mysql.com/41661,
Bug#42185: http://bugs.mysql.com/42185,
Bug#43146: http://bugs.mysql.com/43146,
Bug#43298: http://bugs.mysql.com/43298,
Bug#43299: http://bugs.mysql.com/43299,
Bug#34624: http://bugs.mysql.com/34624,
Bug#42189: http://bugs.mysql.com/42189)
* Use of SELECT * allowed users with rights to only some columns
of a view to access all columns.
(Bug#41354: http://bugs.mysql.com/41354)
* If the tables underlying a MERGE table had a primary key but
the MERGE table itself did not, inserting a duplicate row into
the MERGE table caused a server crash.
(Bug#41305: http://bugs.mysql.com/41305)
* In the help command output displayed by mysql, the description
for the \c (clear) command was misleading.
(Bug#41268: http://bugs.mysql.com/41268)
* Several resource leaks were corrected in the error-handling
code for the MySQL Backup library.
(Bug#41250: http://bugs.mysql.com/41250,
Bug#41294: http://bugs.mysql.com/41294)
* The server did not robustly handle problems hang if a table
opened with HANDLER needed to be re-opened because it had been
altered to use a different storage engine that does not
support HANDLER. The server also failed to set an error if the
re-open attempt failed. These problems could cause the server
to crash or hang. (Bug#41110: http://bugs.mysql.com/41110,
Bug#41112: http://bugs.mysql.com/41112)
* SELECT statements executed concurrently with INSERT statements
for a MyISAM table could cause incorrect results to be
returned from the query cache.
(Bug#41098: http://bugs.mysql.com/41098)
* For prepared statements, multibyte character sets were not
taking into account when calculating max_length for string
values and mysql_stmt_fetch() could return truncated strings.
(Bug#41078: http://bugs.mysql.com/41078)
* For user-defined variables in a query result, incorrect length
values were returned in the result metadata.
(Bug#41030: http://bugs.mysql.com/41030)
* Using RESTORE to restore a database through a named pipe
resulted in corrupt data.
(Bug#40975: http://bugs.mysql.com/40975)
* Performing SELECT operations on Falcon tables using the
maximum BIG INT value would fail to return matching rows.
(Bug#40950: http://bugs.mysql.com/40950)
* For some queries, an equality propagation problem could cause
a = b and b = a to be handled differently.
(Bug#40925: http://bugs.mysql.com/40925)
* With strict SQL mode enabled, setting a system variable to an
out-of-bounds value caused an assertion failure.
(Bug#40657: http://bugs.mysql.com/40657)
* Table temporary scans were slower than necessary due to use of
mmap rather than caching, even with the myisam_use_mmap system
variable disabled. (Bug#40634: http://bugs.mysql.com/40634)
* Indexes on Falcon tables using numeric columns could return
incorrect information.
(Bug#40607: http://bugs.mysql.com/40607,
Bug#41582: http://bugs.mysql.com/41582,
Bug#40950: http://bugs.mysql.com/40950)
* The load_defaults(), my_search_option_files() and
my_print_default_files() functions in the C client library
were subject to a race condition in multi-threaded operation.
(Bug#40552: http://bugs.mysql.com/40552)
* For a view that references a table in another database,
mysqldump wrote the view name qualified with the current
database name. This makes it impossible to reload the dump
file into a different database.
(Bug#40345: http://bugs.mysql.com/40345)
* On platforms where long and pointer variables have different
sizes, MyISAM could copy key statistics incorrectly, resulting
in a server crash or incorrect cardinality values.
(Bug#40321: http://bugs.mysql.com/40321)
* Falcon could cause an assertion when the system has run out of
memory and tries to report the memory allocation failure.
(Bug#40155: http://bugs.mysql.com/40155)
* DELETE tried to acquire write (not read) locks for tables
accessed within a subquery of the WHERE clause.
(Bug#39843: http://bugs.mysql.com/39843)
* mysql_upgrade did not remove the online_backup and
online_backup_progress tables from the mysql database. (These
are what the backup_history and backup_progress tables were
called previously.) (Bug#39655: http://bugs.mysql.com/39655)
* With row-based binary logging, replication of InnoDB tables
containing NULL-valued BIT columns could fail.
(Bug#39648: http://bugs.mysql.com/39648)
* When using Falcon and the system runs out of all memory and
swap space, mysqld could hang while attempting to write an
error message. (Bug#39552: http://bugs.mysql.com/39552)
* The mysql_stmt_close() C API function did not flush all
pending data associated with the prepared statement.
(Bug#39519: http://bugs.mysql.com/39519)
* Updating Falcon tables after an online ALTER ADD COLUMN
operation could fail. (Bug#39445: http://bugs.mysql.com/39445)
* 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: http://bugs.mysql.com/39438)
* perror did not produce correct output for error codes 153 to
163. (Bug#39370: http://bugs.mysql.com/39370)
* If --basedir was specified, mysqld_safe did not use it when
attempting to locate my_print_defaults.
(Bug#39326: http://bugs.mysql.com/39326)
* Several functions in libmysqld called exit() when an error
occurred rather than returning an error to the caller.
(Bug#39289: http://bugs.mysql.com/39289)
* Performing an online ALTER TABLE statement against a Falcon
table, the Falcon serial log could grow beyond the maximum
permitted size for a serial log, ignoring both the rotation
and truncation. (Bug#39130: http://bugs.mysql.com/39130)
* Previously, the num_objects column in the backup_history table
showed only the number of tables in the backup image. It now
shows the number of objects with names (tablespaces,
databases, tables, views, stored programs).
(Bug#39109: http://bugs.mysql.com/39109)
* BACKUP DATABASE treated the database list in case-sensitive
fashion, even on case-insensitive file systems.
(Bug#39063: http://bugs.mysql.com/39063)
* The ALTER ROUTINE privilege incorrectly allowed SHOW CREATE
TABLE. (Bug#38347: http://bugs.mysql.com/38347)
* BACKUP DATABASE crashed if there was no default database.
(Bug#38294: http://bugs.mysql.com/38294)
* Setting a savepoint with the same name as an existing
savepoint incorrectly deleted any other savepoints that had
been set in the meantime. For example, setting savepoints
named a, b, c, b resulted in savepoints a, b, rather than the
correct savepoints a, c, b.
(Bug#38187: http://bugs.mysql.com/38187)
* Locking of myisam.log did not work correctly on Windows.
(Bug#38133: http://bugs.mysql.com/38133,
Bug#41224: http://bugs.mysql.com/41224)
* --help output for myisamchk did not list the --HELP option.
(Bug#38103: http://bugs.mysql.com/38103)
* Setting the session value of the debug system variable also
set the global value. (Bug#38054: http://bugs.mysql.com/38054)
* Comparisons between row constructors, such as (a, b) = (c, d)
resulted in unnecessary Illegal mix of collations errors for
string columns. (Bug#37601: http://bugs.mysql.com/37601)
* A workload consisting of CREATE TABLE ... SELECT and DML
operations could cause deadlock.
(Bug#37433: http://bugs.mysql.com/37433)
* If a user created a view that referenced tables for which the
user had disjoint privileges, an assertion failure occurred.
(Bug#37191: http://bugs.mysql.com/37191)
* Trying to recover Falcon tables after a crash when the
corresponding tables and tablespaces have not been created
before the crash could cause a recovery failure.
(Bug#36993: http://bugs.mysql.com/36993)
* When MySQL was configured with the --with-max-indexes=128
option, mysqld crashed.
(Bug#36751: http://bugs.mysql.com/36751)
* The event, general_log, and slow_log tables in the mysql
database store server_id values, but did not use an UNSIGNED
column and thus were not able to store the full range of ID
values. (Bug#36540: http://bugs.mysql.com/36540)
* Setting the join_buffer_size variable to its minimum value
produced spurious warnings.
(Bug#36446: http://bugs.mysql.com/36446)
* The audit plugin was not receiving MYSQL_AUDIT_GENERAL_ERROR
events. (Bug#36098: http://bugs.mysql.com/36098)
* The use of NAME_CONST() can result in a problem for CREATE
TABLE ... SELECT statements when the source column expressions
refer to local variables. Converting these references to
NAME_CONST() expressions can result in column names that are
different on the master and slave servers, or names that are
too long to be legal column identifiers. A workaround is to
supply aliases for columns that refer to local variables.
Now a warning is issued in such cases that indicate possible
problems. (Bug#35383: http://bugs.mysql.com/35383)
* SHOW CREATE EVENT output did not include the DEFINER clause.
(Bug#35297: http://bugs.mysql.com/35297)
* mysqld would crash in a concurrent workload with INSERT/CREATE
TABLE/DROP TABLE or INSERT/ALTER TABLE combinations on Falcon
tables. (Bug#35255: http://bugs.mysql.com/35255)
* It was not possible to interrupt a long running BACKUP
DATABASE or RESTORE operation.
(Bug#35079: http://bugs.mysql.com/35079)
* Several deprecated or obsolete settings were removed from the
sample option files. (Bug#34521: http://bugs.mysql.com/34521)
* Searching for 0x00 in Falcon tables using the VARBINARY column
type would fail to return the correct rows. In addition, a
crash could be encountered when modifying a column to the
VARBINARY type. (Bug#34478: http://bugs.mysql.com/34478,
Bug#33190: http://bugs.mysql.com/33190,
Bug#23692: http://bugs.mysql.com/23692)
* A subquery using SELECT ... FOR UPDATE on a Falcon table fails
to lock table correctly during the UPDATE.
(Bug#34182: http://bugs.mysql.com/34182)
* With Falcon tables running concurrent transactions, some
transactions may not be rolled back correctly, leading to an
infinite loop. (Bug#34174: http://bugs.mysql.com/34174)
* INSTALL PLUGIN and UNINSTALL PLUGIN did not handle plugin
identifiers consistently with respect to lettercase.
(Bug#33731: http://bugs.mysql.com/33731)
* RESTORE often would not correctly identify the tablespace into
which a Falcon table should be restored.
(Bug#33569: http://bugs.mysql.com/33569)
* mysqldump --compatible=mysql40 emitted statements referring to
the character_set_client system variable, which is unknown
before MySQL 4.1. Now the statements are enclosed in
version-specific comments.
(Bug#33550: http://bugs.mysql.com/33550)
* If Falcon runs out of memory while inserting records and you
try to alter the affected table, you may get a record memory
is exhausted error, and the table can no longer be used or
accessed. (Bug#33177: http://bugs.mysql.com/33177)
* The DDL blocker for BACKUP DATABASE and RESTORE did not block
all statements that it should. The blocker is now called the
Backup Metadata Lock and blocks statements that change
database metadata. (Bug#32702: http://bugs.mysql.com/32702)
* Detection by configure of several functions such as
setsockopt(), bind(), sched_yield(), and gtty() could fail.
(Bug#31506: http://bugs.mysql.com/31506)
* Use of MBR spatial functions such as MBRTouches() with columns
of InnoDB tables caused a server crash rather than an error.
(Bug#31435: http://bugs.mysql.com/31435)
* When an InnoDB tablespace filled up, an error was logged to
the client, but not to the error log. Also, the error message
was misleading and did not indicate the real source of the
problem. (Bug#31183: http://bugs.mysql.com/31183)
* The mysql client mishandled input parsing if a delimiter
command was not first on the line.
(Bug#31060: http://bugs.mysql.com/31060)
* SHOW PRIVILEGES listed the CREATE ROUTINE privilege as having
a context of Functions,Procedures, but it is a database-level
privilege. (Bug#30305: http://bugs.mysql.com/30305)
* CHECK TABLE, REPAIR TABLE, ANALYZE TABLE, and OPTIMIZE TABLE
erroneously reported a table to be corrupt if the table did
not exist or the statement was terminated with KILL.
(Bug#29458: http://bugs.mysql.com/29458)
* For InnoDB tables that have their own .ibd tablespace file, a
superfluous ibuf cursor restoration fails! message could be
written to the error log. This warning has been suppressed.
(Bug#27276: http://bugs.mysql.com/27276)
* Internal base64_xxx() functions were renamed to have a prefix
of my_ to avoid conflicts with other libraries.
(Bug#26818: http://bugs.mysql.com/26818)
* The Time column for SHOW PROCESSLIST output and the value of
the TIME column of the INFORMATION_SCHEMA.PROCESSLIST table
now can have negative values. Previously, the column was
unsigned and negative values were displayed incorrectly as
large positive values. Negative values can occur if a thread
alters the time into the future with SET TIMESTAMP = value or
the thread is executing on a slave and processing events from
a master that has its clock set ahead of the slave.
(Bug#22047: http://bugs.mysql.com/22047)
* Restoring a mysqldump dump file containing FEDERATED tables
failed because the file contained the data for the table. Now
only the table definition is dumped (because the data is
located elsewhere). (Bug#21360: http://bugs.mysql.com/21360)
* SHOW CREATE DATABASE did not account for the value of the
lower_case_table_names system variable.
(Bug#21317: http://bugs.mysql.com/21317)
* Incorrect length metadata could be returned for LONG TEXT
columns when a multibyte server character set was used.
(Bug#19829: http://bugs.mysql.com/19829)
* ROUND() sometimes returned different results on different
platforms. (Bug#15936: http://bugs.mysql.com/15936)
|
|