Author: jstephens
Date: 2007-06-23 10:58:49 +0200 (Sat, 23 Jun 2007)
New Revision: 6899
Log:
Documented Server bugfixes:
Bug #26380, Bug #26711, Bug #27029, Bug #27592, Bug #27716,
Bug #28211, Bug #28904, Bug #28921, Bug #29053, Bug #29130
Modified:
trunk/refman-5.0/releasenotes-es-5.0.xml
trunk/refman-5.1/news-5.1.xml
Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml 2007-06-23 07:33:37 UTC (rev 6898)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml 2007-06-23 08:58:49 UTC (rev 6899)
Changed blocks: 2, Lines Added: 72, Lines Deleted: 0; 3208 bytes
@@ -102,6 +102,70 @@
<listitem>
<para>
+ A stack overrun could when storing <literal>DATETIME</literal>
+ values using repeated prepared statements. (Bug #27592)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>ALTER TABLE ... ENABLE KEYS</literal> could cause
+ <command>mysqld</command> to crash when executed on a table
+ containing on a <literal>MyISAM</literal> table containing
+ billions of rows. (Bug #27029)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Binary content <literal>0x00</literal> in a
+ <literal>BLOB</literal> column sometimes became <literal>0x5C
+ 0x00</literal> following a dump and reload, which could cause
+ problems with data using multi-byte character sets such as
+ <literal>GBK</literal> (Chinese). This was due to a problem
+ with <literal>SELECT INTO OUTFILE</literal> whereby
+ <literal>LOAD DATA</literal> later incorrectly interpreted
+ <literal>0x5C</literal> as the second byte of a multi-byte
+ sequence rather than as the <literal>SOLIDUS</literal>
+ (<quote>\</quote>) character, used by MySQL as the escape
+ character. (Bug #26711)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If one of the queries in a <literal>UNION</literal> used the
+ <literal>SQL_CACHE</literal> option and another query in the
+ <literal>UNION</literal> contained a nondeterministic
+ function, the result was still cached. For example, this query
+ was incorrectly cached:
+
+<programlisting>
+SELECT NOW() FROM t1 UNION SELECT SQL_CACHE 1 FROM t1;
+</programlisting>
+
+ (Bug #29053)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Queries using UDFs or stored functions were cached. (Bug
+ #28921)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The modification of a table by a partially completed
+ multi-column update was not recorded in the binlog, rather
+ than being marked by an event and a corresponding error code.
+ (Bug #27716)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Non-<literal>utf8</literal> characters could get mangled when
stored in <literal>CSV</literal> tables. (Bug #28862)
</para>
@@ -273,6 +337,14 @@
<listitem>
<para>
+ <literal>INSERT .. ON DUPLICATE KEY UPDATE</literal> could
+ under some circumstances silently update rows when it should
+ not have. (Bug #28904)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Connections from one <command>mysqld</command> server to
another failed on Mac OS X, affecting replication and
<literal>FEDERATED</literal> tables. (Bug #26664)
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2007-06-23 07:33:37 UTC (rev 6898)
+++ trunk/refman-5.1/news-5.1.xml 2007-06-23 08:58:49 UTC (rev 6899)
Changed blocks: 2, Lines Added: 99, Lines Deleted: 0; 4108 bytes
@@ -200,6 +200,21 @@
<listitem>
<para>
+ A stack overrun could when storing <literal>DATETIME</literal>
+ values using repeated prepared statements. (Bug #27592)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>INSERT .. ON DUPLICATE KEY UPDATE</literal> could
+ under some circumstances silently update rows when it should
+ not have. (Bug #28904)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Using events in replication could cause the slave to crash.
(Bug #28953)
</para>
@@ -207,6 +222,90 @@
<listitem>
<para>
+ <literal>ALTER TABLE ... ENABLE KEYS</literal> could cause
+ <command>mysqld</command> to crash when executed on a table
+ containing on a <literal>MyISAM</literal> table containing
+ billions of rows. (Bug #27029)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A <literal>FLUSH TABLES WITH READ LOCK</literal> statement
+ followed by a <literal>FLUSH LOGS</literal> statement caused a
+ deadlock if the general log or the slow query log was enabled.
+ (Bug #26380)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>TRUNCATE</literal> statement was handled
+ differently by the server when row-based logging was in
+ effect, even though the binlogging format in effect does not
+ effect the fact that <literal>TRUNCATE</literal> is always
+ logged as a statement. (Bug #29130)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ When the query cache was fully used, issuing <literal>RENAME
+ DATABASE</literal> or <literal>RENAME SCHEMA</literal> could
+ cause the server to hang, with 100% CPU usage. (Bug #28211)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Binary content <literal>0x00</literal> in a
+ <literal>BLOB</literal> column sometimes became <literal>0x5C
+ 0x00</literal> following a dump and reload, which could cause
+ problems with data using multi-byte character sets such as
+ <literal>GBK</literal> (Chinese). This was due to a problem
+ with <literal>SELECT INTO OUTFILE</literal> whereby
+ <literal>LOAD DATA</literal> later incorrectly interpreted
+ <literal>0x5C</literal> as the second byte of a multi-byte
+ sequence rather than as the <literal>SOLIDUS</literal>
+ (<quote>\</quote>) character, used by MySQL as the escape
+ character. (Bug #26711)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If one of the queries in a <literal>UNION</literal> used the
+ <literal>SQL_CACHE</literal> option and another query in the
+ <literal>UNION</literal> contained a nondeterministic
+ function, the result was still cached. For example, this query
+ was incorrectly cached:
+
+<programlisting>
+SELECT NOW() FROM t1 UNION SELECT SQL_CACHE 1 FROM t1;
+</programlisting>
+
+ (Bug #29053)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Queries using UDFs or stored functions were cached. (Bug
+ #28921)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The modification of a table by a partially completed
+ multi-column update was not recorded in the binlog, rather
+ than being marked by an event and a corresponding error code.
+ (Bug #27716)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>SHOW ENGINES</literal> and queries on
<literal>INFORMATION_SCHEMA.ENGINES</literal> did not use the
same values for representing the same storage engine states.
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6899 - in trunk: refman-5.0 refman-5.1 | jon | 23 Jun |
