Author: jstephens
Date: 2005-10-19 17:30:20 +0200 (Wed, 19 Oct 2005)
New Revision: 98
Log:
refman-common/news-4.0.xml
- Documented fixes for Bug#13855, Bug#7672 (moved from 4.0.24 to 4.0.27 changelog), Bug#12823
refman-common/news-4.1.xml
- Documented fixes for Bug#13919/Bug#13048, Bug#7672, Bug#8731, Bug#12823
refman-common/news-5.0.xml
- Documented fixes for Bug#13919/Bug#13048, Bug#7672, Bug#8731, Bug#13504, Bug#13484, Bug#12823
Modified:
trunk/refman-common/news-4.0.xml
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml
Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml 2005-10-19 12:53:47 UTC (rev 97)
+++ trunk/refman-common/news-4.0.xml 2005-10-19 15:30:20 UTC (rev 98)
@@ -143,6 +143,20 @@
</para>
<itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>MySQL-server</literal> RPM now explicitly assigns
+ the <literal>mysql</literal> system user to the
+ <literal>mysql</literal> user group during the
+ postinstallation process. This corrects an issue with
+ upgrading the server on some Linux distributions whereby a
+ previously existing <literal>mysql</literal> user was not
+ changed to the <literal>mysql</literal> group, resulting in
+ wrong groups for files created following the installation.
+ (Bug #12823)
+ </para>
+ </listitem>
<listitem>
<para>
@@ -162,6 +176,24 @@
<listitem>
<para>
+ Queries of the form <literal>(SELECT ...) ORDER BY
+ ...</literal> were being treated as a
+ <literal>UNION</literal>. This improperly resulted in only
+ distinct values being returned (because
+ <literal>UNION</literal> by default eliminates duplicate
+ results). (Bug #7672)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>SELECT DISTINCT</literal> with a <literal>GROUP
+ BY</literal> clause caused a server crash. (Bug #13855)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>SHOW CREATE TABLE</literal> did not display any
<literal>FOREIGN KEY</literal> clauses if a temporary file
could not be created. Now <literal>SHOW CREATE TABLE</literal>
@@ -253,9 +285,9 @@
<para>
Bugs fixed:
</para>
-
- <itemizedlist>
-
+
+ <itemizedlist>
+
<listitem>
<para>
An optimizer estimate of zero rows for a non-empty
@@ -683,16 +715,6 @@
<listitem>
<para>
- Queries of the form <literal>(SELECT ...) ORDER BY
- ...</literal> were being treated as a
- <literal>UNION</literal>. This improperly resulted in only
- distinct values being returned (because
- <literal>UNION</literal> by default eliminates.) (Bug #7672)
- </para>
- </listitem>
-
- <listitem>
- <para>
Index cardinality was not being updated properly for
<literal>TEMPORARY</literal> tables under some circumstances,
such as <literal>CREATE TABLE ... SELECT</literal> followed by
Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2005-10-19 12:53:47 UTC (rev 97)
+++ trunk/refman-common/news-4.1.xml 2005-10-19 15:30:20 UTC (rev 98)
@@ -160,25 +160,29 @@
describing the bugfix, like this: This sentence describes the fix.
(Bug #nnnn)
</remark>
-
- <remark role="todo">
- [js] Uncomment following if/when needed.
- </remark>
-<!--
+
<para>
Functionality added or changed:
</para>
<itemizedlist>
-
+
<listitem>
<para>
-
+ The <literal>MySQL-server</literal> RPM now explicitly assigns
+ the <literal>mysql</literal> system user to the
+ <literal>mysql</literal> user group during the
+ postinstallation process. This corrects an issue with
+ upgrading the server on some Linux distributions whereby a
+ previously existing <literal>mysql</literal> user was not
+ changed to the <literal>mysql</literal> group, resulting in
+ wrong groups for files created following the installation.
+ (Bug #12823)
</para>
</listitem>
</itemizedlist>
--->
+
<para>
Bugs fixed:
</para>
@@ -192,6 +196,26 @@
<listitem>
<para>
+ The <option>--interactive-timeout</option> and
+ <option>--slave-net-timeout</option> options for
+ <command>mysqld</command> were not being obeyed on Mac OS X
+ and other BSD-based platforms. (Bug #8731)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Queries of the form <literal>(SELECT ...) ORDER BY
+ ...</literal> were being treated as a
+ <literal>UNION</literal>. This improperly resulted in only
+ distinct values being returned (because
+ <literal>UNION</literal> by default eliminates duplicate
+ results). (Bug #7672)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Multiple update queries using any type of subquery would be
ignored by a replication slave when a condition such as
<option>--replicate-ignore-table</option> like condition was
@@ -317,6 +341,16 @@
<listitem>
<para>
+ If special characters such as <literal>'_'</literal> ,
+ <literal>'%'</literal>, or the escape character were included
+ within the prefix of a column index, <literal>LIKE</literal>
+ pattern matching on the indexed column did not return the
+ correct result. (Bug #13046, Bug #13919)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>NDBCluster</literal>: Updating a text-type column
during a cluster backup could cause the
<command>ndbd</command> process to crash, due to the incorrect
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2005-10-19 12:53:47 UTC (rev 97)
+++ trunk/refman-common/news-5.0.xml 2005-10-19 15:30:20 UTC (rev 98)
@@ -172,6 +172,20 @@
</para>
<itemizedlist>
+
+ <listitem>
+ <para>
+ The <literal>MySQL-server</literal> RPM now explicitly assigns
+ the <literal>mysql</literal> system user to the
+ <literal>mysql</literal> user group during the
+ postinstallation process. This corrects an issue with
+ upgrading the server on some Linux distributions whereby a
+ previously existing <literal>mysql</literal> user was not
+ changed to the <literal>mysql</literal> group, resulting in
+ wrong groups for files created following the installation.
+ (Bug #12823)
+ </para>
+ </listitem>
<listitem>
<para>
@@ -298,9 +312,57 @@
</para>
<itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>InnoDB</literal>: Queries that were executed using an
+ <literal>index_merge</literal> union or intersection could
+ produce incorrect results if the underlying table used the
+ <literal>InnoDB</literal> storage engine and had a primary key
+ containing <literal>VARCHAR</literal> members. (Bug #13484)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>CREATE DEFINER=... VIEW ...</literal> caused the
+ server to crash when run with
+ <option>--skip-grant-tables</option>. (Bug #)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <option>--interactive-timeout</option> and
+ <option>--slave-net-timeout</option> options for
+ <command>mysqld</command> were not being obeyed on Mac OS X
+ and other BSD-based platforms. (Bug #8731)
+ </para>
+ </listitem>
<listitem>
<para>
+ Queries of the form <literal>(SELECT ...) ORDER BY
+ ...</literal> were being treated as a
+ <literal>UNION</literal>. This improperly resulted in only
+ distinct values being returned (because
+ <literal>UNION</literal> by default eliminates duplicate
+ results). (Bug #7672)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If special characters such as <literal>'_'</literal> ,
+ <literal>'%'</literal>, or the escape character were included
+ within the prefix of a column index, <literal>LIKE</literal>
+ pattern matching on the indexed column did not return the
+ correct result. (Bug #13046, Bug #13919)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
An <literal>UPDATE</literal> query using a join would be
executed incorrectly on a replication slave. (Bug #12618)
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r98 - trunk/refman-common | jstephens | 19 Oct |
