Author: jstephens
Date: 2006-01-25 01:47:20 +0100 (Wed, 25 Jan 2006)
New Revision: 1025
Log:
Documented bugfixes:
15538, 15633, 15658, 16510, 15787, 14189
16095, 3300 (partial), 12734, 14037
Modified:
trunk/refman-5.0/data-types.xml
trunk/refman-5.0/innodb.xml
trunk/refman-5.0/optimization.xml
trunk/refman-5.1/optimization.xml
trunk/refman-common/news-4.0.xml
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml
trunk/refman-common/news-5.1.xml
Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-5.0/data-types.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -3850,6 +3850,15 @@
Before MySQL 5.0.15, trailing 0x00 bytes are removed for
<literal>ORDER BY</literal> operations.)
</para>
+
+ <para>
+ Note that the <literal>InnoDB</literal> storage engine continues
+ to preserve trailing spaces in <literal>BINARY</literal> and
+ <literal>VARBINARY</literal> column values through MySQL 5.0.18,
+ and then, beginning with MySQL 5.0.19, ignores trailing space
+ characters in making comparisons as do other MySQL storage
+ engines.
+ </para>
<para>
For those cases where trailing pad bytes are stripped or
Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-5.0/innodb.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -7094,6 +7094,16 @@
actions.
</para>
</listitem>
+
+ <listitem>
+ <para>
+ Prior to MySQL 5.0.19, <literal>InnoDB</literal> does not
+ ignore trailing spaces when comparing
+ <literal>BINARY</literal> or <literal>VARBINARY</literal>
+ column values. See <xref linkend="binary-varbinary"/> and
+ <xref linkend="news-5-0-19"/>.
+ </para>
+ </listitem>
</itemizedlist>
Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-5.0/optimization.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -2939,6 +2939,13 @@
(<replaceable>x</replaceable> OR <replaceable>y</replaceable>) AND <replaceable>z</replaceable> = (<replaceable>x</replaceable> AND <replaceable>z</replaceable>) OR (<replaceable>y</replaceable> AND <replaceable>z</replaceable>)
</programlisting>
</listitem>
+
+ <listitem>
+ <para>
+ Index Merge is not applicable to fulltext indexes. We plan
+ to extend it to cover these in a future MySQL release.
+ </para>
+ </listitem>
</itemizedlist>
Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-5.1/optimization.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -2961,6 +2961,13 @@
(<replaceable>x</replaceable> OR <replaceable>y</replaceable>) AND <replaceable>z</replaceable> = (<replaceable>x</replaceable> AND <replaceable>z</replaceable>) OR (<replaceable>y</replaceable> AND <replaceable>z</replaceable>)
</programlisting>
</listitem>
+
+ <listitem>
+ <para>
+ Index Merge is not applicable to fulltext indexes. We plan
+ to extend it to cover these in a future MySQL release.
+ </para>
+ </listitem>
</itemizedlist>
Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-common/news-4.0.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -173,6 +173,19 @@
</para>
<itemizedlist>
+
+ <listitem>
+ <para>
+ An <literal>UPDATE</literal> statement which tried to update a
+ column with a name beginning with an asterisk would cause the
+ server to crash. This was because mysqld would wrongly expand
+ the <literal>*</literal> character to the list of all table
+ columns, causing the list of columns to become longer than the
+ list of values. Now the server performs this expansion only if
+ the <literal>*</literal> character is followed by a space.
+ (Bug #15610)
+ </para>
+ </listitem>
<listitem>
<para>
Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-common/news-4.1.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -172,13 +172,6 @@
</listitem>
</itemizedlist>
-
- <remark role="todo">
- [js] Uncomment when there are bugfixes to document for this
- release.
- </remark>
-
-<!--
<para>
Bugs fixed:
@@ -187,12 +180,15 @@
<itemizedlist>
<listitem>
<para>
-
+ A prepared statement created from a <literal>SELECT ...
+ LIKE</literal> query (such as <literal>PREPARE stmt1 FROM
+ 'SELECT col_1 FROM tedd_test WHERE col_1 LIKE
+ ?';</literal>) would begin to produce erratic results
+ after being executed repeatedly numerous (thousands) of times.
+ (Bug #12734)
</para>
</listitem>
</itemizedlist>
-
- -->
</section>
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-common/news-5.0.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -176,8 +176,28 @@
</para>
<itemizedlist>
+
<listitem>
<para>
+ <emphasis role="bold">Incompatible change</emphasis>: The
+ <literal>InnoDB</literal> storage engine no longer ignores
+ trailing spaces when comparing <literal>BINARY</literal> or
+ <literal>VARBINARY</literal> column values. This means that (for
+ example) the binary values <literal>'a'</literal> and
+ <literal>'a '</literal> are now regarded as
+ <emphasis>unequal</emphasis> any time they are compared, as
+ they are in <literal>MyISAM</literal> tables. (Bug #14189)
+ </para>
+
+ <para>
+ See <xref linkend="binary-varbinary"/> for more information
+ about the <literal>BINARY</literal> and
+ <literal>VARBINARY</literal> types.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>NDB Cluster</literal>: More descriptive warnings are
now issued when inappropriate logging parameters are set in
<filename>config.ini</filename>. (Formerly, the warning issued
@@ -223,6 +243,50 @@
<listitem>
<para>
+ A prepared statement created from a <literal>SELECT ...
+ LIKE</literal> query (such as <literal>PREPARE stmt1 FROM
+ 'SELECT col_1 FROM tedd_test WHERE col_1 LIKE
+ ?';</literal>) would begin to produce erratic results
+ after being executed repeatedly numerous (thousands) of times.
+ (Bug #12734)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The server would crash when the size of an
+ <literal>ARCHIVE</literal> table grew beyond 2GB. (Bug #15787)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Created a user function with an empty string (that is,
+ <literal>CREATE FUNCTION ''()</literal>), was accepted by the
+ server. Following this, calling <literal>SHOW FUNCTION
+ STATUS</literal> would cause the server to crash. (Bug
+ #15658)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ In some cases the query optimizer did not properly perform
+ multiple joins where inner joins followed left joins,
+ resulting in corrupted result sets. (Bug #15633)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The absence of a table in the left part of a left or right
+ join was not checked prior to name resolution, which resulted
+ in a server crash. (Bug #15538)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>NDBCluster</literal>: A bitfield whose offset and
length totaled 32 would crash the cluster. (Bug #16125)
</para>
Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml 2006-01-24 21:13:18 UTC (rev 1024)
+++ trunk/refman-common/news-5.1.xml 2006-01-25 00:47:20 UTC (rev 1025)
@@ -177,6 +177,22 @@
<listitem>
<para>
+ In some cases the query optimizer did not properly perform
+ multiple joins where inner joins followed left joins,
+ resulting in corrupted result sets. (Bug #15633)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The absence of a table in the left part of a left or right
+ join was not checked prior to name resolution, which resulted
+ in a server crash. (Bug #15538)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>NDB Cluster</literal>: Trying to import too many
dumped tables requiring resources beyond those allocated in
the cluster configuration would cause the server to crash
@@ -515,6 +531,21 @@
</para>
<itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>InnoDB</literal>: An <literal>UPDATE</literal>
+ statement with no index column in the <literal>WHERE</literal>
+ condition locked all the rows in the table. (Bug #3300)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>INSERT DELAYED</literal> caused
+ <command>mysqld</command> to crash. (Bug #16095)
+ </para>
+ </listitem>
<listitem>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1025 - in trunk: refman-5.0 refman-5.1 refman-common | jon | 25 Jan |
