Author: jstephens
Date: 2007-11-14 19:56:12 +0100 (Wed, 14 Nov 2007)
New Revision: 8713
Log:
Clobbered some more dupes in the changelog
Modified:
trunk/dynamic-docs/changelog/dupes.txt
trunk/dynamic-docs/changelog/mysqld.xml
Modified: trunk/dynamic-docs/changelog/dupes.txt
===================================================================
--- trunk/dynamic-docs/changelog/dupes.txt 2007-11-14 17:27:18 UTC (rev 8712)
+++ trunk/dynamic-docs/changelog/dupes.txt 2007-11-14 18:56:12 UTC (rev 8713)
Changed blocks: 2, Lines Added: 25, Lines Deleted: 24; 711 bytes
@@ -223,30 +223,31 @@
23502x
23556x
23667x
-24089
-24148
-24158
-24166
-24200
-24227
-24228
-24563
-24630
-24653
-24660
-24664
-24667
-24778
-24795
-24914
-24917
-24949
-25001
-25059
-25090
-25239
+24089x
+24148x
+24158x
+24166x
+24200x
+24227x
+24228x
+24563x
+24630x
+24653x
+24660x
+24664x
+24667x
+24778x
+24795x
+24914x
+24917x
+24949x
+25001x
+25059x
+25090x
+25239x
+25296x
25422x
-25530
+25530x
25578x
25621
25686
@@ -270,7 +271,7 @@
26503
26514
26515
-26556
+26556x
26591
26662
26720
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2007-11-14 17:27:18 UTC (rev 8712)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2007-11-14 18:56:12 UTC (rev 8713)
Changed blocks: 52, Lines Added: 133, Lines Deleted: 692; 27405 bytes
@@ -5708,6 +5708,7 @@
<versions>
<version ver="5.1.15"/>
<version ver="5.0.36"/>
+ <version ver="5.0.37"/>
</versions>
<message>
@@ -8452,7 +8453,7 @@
<message>
<para>
- The following changes were made for the
+ The following changes were made in the
<command>ndb_size.pl</command> utility:
<itemizedlist>
@@ -13156,14 +13157,15 @@
<versions>
<version ver="5.1.14-ndb-6.1.0"/>
+ <version ver="5.1.15"/>
</versions>
<message>
<para>
- A <literal>MEDIUMTEXT</literal> column of a Disk Data table was
- stored in memory rather than on disk, even if the column was not
- indexed.
+ <literal>MEDIUMTEXT</literal> columns of Disk Data tables were
+ stored in memory rather than on disk, even if the columns were
+ not indexed.
</para>
</message>
@@ -16409,26 +16411,6 @@
</logentry>
- <logentry entrytype="feature">
-
- <bugs>
- <fixes bugid="24228"/>
- </bugs>
-
- <versions>
- <version ver="5.1.18"/>
- </versions>
-
- <message>
-
- <para>
- The dependency on <literal>HTML::Template</literal> was removed.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="bug">
<bugs>
@@ -18790,33 +18772,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- </tags>
-
- <bugs>
- <fixes bugid="25059"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- <version ver="5.0.37"/>
- <version ver="5.0.34"/>
- </versions>
-
- <message>
-
- <para>
- (NDB API): A unique index lookup on a non-existent tuple could
- lead to a data node timeout (error 4012).
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="myisamchk"/>
</tags>
@@ -20668,40 +20623,6 @@
<tags>
<highlight type="cluster"/>
- <manual type="DBTC"/>
- <manual type="AO_IgnoreError"/>
- <manual type="transactions"/>
- <manual type="Commit"/>
- </tags>
-
- <bugs>
- <fixes bugid="25090"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- <version ver="5.0.37"/>
- <version ver="5.0.34"/>
- </versions>
-
- <message>
-
- <para>
- (NDB API): Invoking the
- <literal>NdbTransaction::execute()</literal> method using
- execution type <literal>Commit</literal> and abort option
- <literal>AO_IgnoreError</literal> could lead to a crash of the
- transaction coordinator (<literal>DBTC</literal>).
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
- <highlight type="cluster"/>
<manual type="ndb_error_reporter"/>
<manual type="ndb_size.pl"/>
</tags>
@@ -28001,7 +27922,6 @@
<para>
This was done to resolve the following interrelated issues:
-
<itemizedlist>
<listitem>
@@ -29618,38 +29538,6 @@
</logentry>
- <logentry entrytype="bug">
-
- <tags>
- <manual type="ORDER BY"/>
- <manual type="GROUP BY"/>
- </tags>
-
- <bugs>
- <fixes bugid="24653"/>
- </bugs>
-
- <versions>
- <version ver="5.0.36"/>
- <version ver="5.0.37"/>
- <version ver="5.1.16"/>
- </versions>
-
- <message>
-
- <para>
- If an <literal>ORDER BY</literal> or <literal>GROUP BY</literal>
- list included a constant expression being optimized away and, at
- the same time, containing single-row subselects that return more
- that one row, no error was reported. If a query requires sorting
- by expressions containing single-row subselects that return more
- than one row, execution of the query may cause a server crash.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="feature">
<tags>
@@ -31001,33 +30889,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- <manual type="MEDIUMTEXT"/>
- </tags>
-
- <bugs>
- <fixes bugid="25001"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- </versions>
-
- <message>
-
- <para>
- (Disk Data): A <literal>MEDIUMTEXT</literal> column of a Disk
- Data table was stored in memory rather than on disk, even if the
- column was not indexed.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="SHOW"/>
</tags>
@@ -33746,38 +33607,6 @@
</logentry>
- <logentry entrytype="feature">
-
- <tags>
- <highlight type="incompatiblechange"/>
- <manual type="InnoDB"/>
- <manual type="transactions"/>
- <manual type="innodb_rollback_on_timeout"/>
- </tags>
-
- <bugs>
- <fixes bugid="24200"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- </versions>
-
- <message>
-
- <para>
- In MySQL ¤t-series;, <literal>InnoDB</literal> rolls back
- only the last statement on a transaction timeout. A new option,
- <option>--innodb_rollback_on_timeout</option>, causes
- <literal>InnoDB</literal> to abort and roll back the entire
- transaction if a transaction timeout occurs (the same behavior
- as in MySQL 4.1).
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="bug">
<tags>
@@ -36529,7 +36358,10 @@
</bugs>
<versions>
+ <version ver="5.0.34"/>
+ <version ver="5.0.37"/>
<version ver="5.1.14-ndb-6.1.0"/>
+ <version ver="5.1.15"/>
</versions>
<message>
@@ -39024,25 +38856,66 @@
</bugs>
<versions>
+ <version ver="4.1.23"/>
+ <version ver="5.0.36"/>
+ <version ver="5.0.37"/>
<version ver="5.1.15"/>
</versions>
+ <message ver="4.1.23">
+
+ <para>
+ For <literal>ENUM</literal> columns that had enumeration values
+ containing commas, the commas were mapped to
+ <literal>0xff</literal> internally. However, this rendered the
+ commas indistinguishable from true <literal>0xff</literal>
+ characters in the values. This no longer occurs. However, the
+ fix requires that you dump and reload any tables that have
+ <literal>ENUM</literal> columns containing any true
+ <literal>0xff</literal> values. Dump the tables using
+ <command>mysqldump</command> with the current server before
+ upgrading from a version of MySQL 4.1 older than 4.1.23 to
+ version 4.1.23 or newer.
+ </para>
+
+ </message>
+
<message>
<para>
For <literal>ENUM</literal> columns that had enumeration values
- containing commas, the commas were mapped to 0xff internally.
- However, this rendered the commas indistinguishable from true
- 0xff characters in the values. This no longer occurs. However,
- the fix requires that you dump and reload any tables that have
- <literal>ENUM</literal> columns containing true 0xff in their
- values: Dump the tables using <command>mysqldump</command> with
- the current server before upgrading from a version of MySQL 5.1
- older than 5.1.15 to version 5.1.15 or newer.
+ containing commas, the commas were mapped to
+ <literal>0xff</literal> internally. However, this rendered the
+ commas indistinguishable from true <literal>0xff</literal>
+ characters in the values. This no longer occurs. However, the
+ fix requires that you dump and reload any tables that have
+ <literal>ENUM</literal> columns containing any true
+ <literal>0xff</literal> values. Dump the tables using
+ <command>mysqldump</command> with the current server before
+ upgrading from a version of MySQL 5.0 older than 5.0.36 to
+ version 5.0.36 or newer.
</para>
</message>
+ <message ver="5.1.15">
+
+ <para>
+ For <literal>ENUM</literal> columns that had enumeration values
+ containing commas, the commas were mapped to
+ <literal>0xff</literal> internally. However, this rendered the
+ commas indistinguishable from true <literal>0xff</literal>
+ characters in the values. This no longer occurs. However, the
+ fix requires that you dump and reload any tables that have
+ <literal>ENUM</literal> columns containing any true
+ <literal>0xff</literal> values. Dump the tables using
+ <command>mysqldump</command> with the current server before
+ upgrading from a version of MySQL 5.1 older than 5.1.15 to
+ version 5.1.15 or newer.
+ </para>
+
+ </message>
+
</logentry>
<logentry entrytype="bug">
@@ -41879,6 +41752,9 @@
<versions>
<version ver="4.1.23"/>
+ <version ver="5.0.36"/>
+ <version ver="5.0.37"/>
+ <version ver="5.1.16"/>
</versions>
<message>
@@ -47509,36 +47385,7 @@
<logentry entrytype="bug">
- <tags>
- <manual type="ORDER BY"/>
- <manual type="subqueries"/>
- <manual type="INFORMATION_SCHEMA"/>
- </tags>
-
<bugs>
- <fixes bugid="26556"/>
- <fixes bugid="24630"/>
- </bugs>
-
- <versions>
- <version ver="5.0.37"/>
- </versions>
-
- <message>
-
- <para>
- Using an <literal>INFORMATION_SCHEMA</literal> table with
- <literal>ORDER BY</literal> in a subquery could cause a server
- crash.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <bugs>
<fixes bugid="18930"/>
</bugs>
@@ -53403,31 +53250,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- </tags>
-
- <bugs>
- <fixes bugid="24917"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- </versions>
-
- <message>
-
- <para>
- (Disk Data): Performing a node restart with a newly dropped Disk
- Data table could lead to failure of the node during the restart.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="ORDER BY"/>
<manual type="GROUP_CONCAT"/>
</tags>
@@ -56534,33 +56356,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- <manual type="transactions"/>
- </tags>
-
- <bugs>
- <fixes bugid="24914"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- </versions>
-
- <message>
-
- <para>
- (NDB API): Due to an error in the computation of table fragment
- arrays, some transactions might not be executed from the correct
- starting point.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="grant_cache"/>
<manual type="mysql-test-run"/>
</tags>
@@ -56746,6 +56541,7 @@
<versions>
<version ver="5.0.36"/>
<version ver="5.0.37"/>
+ <version ver="5.1.15"/>
</versions>
<message>
@@ -56753,9 +56549,9 @@
<para>
When <literal>SET PASSWORD</literal> was written to the binary
log double quotes were included in the statement. If the slave
- was running in with the <literal>sql_mode</literal> set to
- <literal>ANSI_QUOTES</literal> the event would fail and halt the
- replication process.
+ was running in with the server SQL mode set to
+ <literal>ANSI_QUOTES</literal>, then the event failed, which
+ halted the replication process.
</para>
</message>
@@ -58302,7 +58098,10 @@
</bugs>
<versions>
+ <version ver="5.0.34"/>
+ <version ver="5.0.37"/>
<version ver="5.1.14-ndb-6.1.0"/>
+ <version ver="5.1.15"/>
</versions>
<message>
@@ -62244,35 +62043,6 @@
<logentry entrytype="bug">
<tags>
- <manual type="configure"/>
- <manual type="with-readline"/>
- </tags>
-
- <bugs>
- <fixes bugid="25530"/>
- </bugs>
-
- <versions>
- <version ver="5.0.36"/>
- <version ver="5.0.37"/>
- </versions>
-
- <message>
-
- <para>
- The <option>--with-readline</option> option for
- <command>configure</command> does not work for commercial source
- packages, but no error message was printed to that effect. Now a
- message is printed.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="subqueries"/>
</tags>
@@ -62645,30 +62415,6 @@
<logentry entrytype="bug">
<tags>
- <manual type="SSL"/>
- </tags>
-
- <bugs>
- <fixes bugid="24148"/>
- </bugs>
-
- <versions>
- <version ver="5.0.37"/>
- </versions>
-
- <message>
-
- <para>
- SSL connections could hang at connection shutdown.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="with-pstack"/>
</tags>
@@ -69784,37 +69530,6 @@
<logentry entrytype="bug">
<tags>
- <manual type="replication"/>
- <manual type="ANSI_QUOTES"/>
- <manual type="binary log"/>
- <manual type="SET PASSWORD"/>
- </tags>
-
- <bugs>
- <fixes bugid="24158"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- </versions>
-
- <message>
-
- <para>
- When <literal>SET PASSWORD</literal> was written to the binary
- log double quotes were included in the statement. If the slave
- was running in with the sql_mode set to
- <literal>ANSI_QUOTES</literal> the event would fail and halt the
- replication process.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="BLOB"/>
</tags>
@@ -70477,19 +70192,20 @@
<bugs>
<fixes bugid="24089"/>
+ <introducedby bugid="15653"/>
</bugs>
<versions>
- <version ver="5.0.33"/>
- <version ver="5.0.30"/>
<version ver="4.1.23"/>
+ <version ver="5.0.30"/>
+ <version ver="5.0.33"/>
</versions>
<message>
<para>
There was a race condition in the <literal>InnoDB</literal>
- <literal>fil_flush_file_spaces()</literal> function.
+ <function>fil_flush_file_spaces()</function> function.
</para>
</message>
@@ -73473,12 +73189,25 @@
<bugs>
<fixes bugid="24667"/>
+ <fixes bugid="25296"/>
</bugs>
<versions>
+ <version ver="5.1.15"/>
<version ver="5.1.15-ndb-6.1.7"/>
+ <version ver="5.1.18"/>
</versions>
+ <message ver="5.1.15">
+
+ <para>
+ Changing a column specification or issuing a
+ <literal>TRUNCATE</literal> statement on a Disk Data table
+ caused the table to become an in-memory table.
+ </para>
+
+ </message>
+
<message>
<para>
@@ -73487,6 +73216,11 @@
caused the table to become an in-memory table.
</para>
+ <para>
+ This fix supersedes an incomplete fix that was made for this
+ issue in MySQL 5.1.15.
+ </para>
+
</message>
</logentry>
@@ -81408,7 +81142,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="clusterapi"/>
</tags>
<bugs>
@@ -81424,9 +81158,9 @@
<message>
<para>
- (NDB API): The <literal>NdbOperation::getBlobHandle()</literal>
- method, when called with the name of a nonexistent column,
- caused a segmentation fault.
+ The <literal>NdbOperation::getBlobHandle()</literal> method,
+ when called with the name of a nonexistent column, caused a
+ segmentation fault.
</para>
</message>
@@ -81436,40 +81170,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="incompatiblechange"/>
- <manual type="ENUM"/>
- <manual type="mysqldump"/>
- </tags>
-
- <bugs>
- <fixes bugid="24660"/>
- </bugs>
-
- <versions>
- <version ver="4.1.23"/>
- </versions>
-
- <message>
-
- <para>
- For <literal>ENUM</literal> columns that had enumeration values
- containing commas, the commas were mapped to 0xff internally.
- However, this rendered the commas indistinguishable from true
- 0xff characters in the values. This no longer occurs. However,
- the fix requires that you dump and reload any tables that have
- <literal>ENUM</literal> columns containing true 0xff in their
- values: Dump the tables using <command>mysqldump</command> with
- the current server before upgrading from a version of MySQL 4.1
- older than 4.1.23 to version 4.1.23 or newer.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="CONVERT_TZ"/>
</tags>
@@ -94049,34 +93749,7 @@
<logentry entrytype="bug">
- <tags>
- <highlight type="diskdata"/>
- <manual type="cluster"/>
- </tags>
-
<bugs>
- <fixes bugid="24166"/>
- </bugs>
-
- <versions>
- <version ver="5.1.14-ndb-6.1.0"/>
- </versions>
-
- <message>
-
- <para>
- When restoring from backup a cluster containing any Disk Data
- tables with hidden primary keys, a node failure resulted which
- could lead to a crash of the cluster.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <bugs>
<fixes bugid="8880"/>
</bugs>
@@ -94801,14 +94474,14 @@
</tags>
<bugs>
- <fixes bugid="24089"/>
+ <fixes bugid="24219"/>
</bugs>
<versions>
+ <version ver="4.1.23"/>
+ <version ver="5.0.32"/>
<version ver="5.0.33"/>
<version ver="5.1.15"/>
- <version ver="5.0.32"/>
- <version ver="4.1.23"/>
</versions>
<message>
@@ -96445,6 +96118,7 @@
</bugs>
<versions>
+ <version ver="5.1.15-ndb-6.1.3"/>
<version ver="5.1.16"/>
</versions>
@@ -96479,34 +96153,6 @@
<logentry entrytype="bug">
<tags>
- <manual type="configure"/>
- <manual type="with-readline"/>
- </tags>
-
- <bugs>
- <fixes bugid="25530"/>
- </bugs>
-
- <versions>
- <version ver="5.1.16"/>
- </versions>
-
- <message>
-
- <para>
- The <option>--with-readline</option> option for
- <command>configure</command> did not work for commercial source
- packages, but no error message was printed to that effect. Now a
- message is printed.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<highlight type="cluster"/>
<manual type="TEXT"/>
<manual type="BLOB"/>
@@ -97625,6 +97271,7 @@
</bugs>
<versions>
+ <version ver="5.1.14-ndb-6.1.0"/>
<version ver="5.1.15"/>
</versions>
@@ -98433,14 +98080,15 @@
<versions>
<version ver="5.1.14-ndb-6.1.0"/>
+ <version ver="5.1.15"/>
</versions>
<message>
<para>
Due to an error in the computation of table fragment arrays,
- some transactions might not be executed from the correct
- starting point.
+ some transactions were not executed from the correct starting
+ point.
</para>
</message>
@@ -99241,7 +98889,7 @@
</tags>
<bugs>
- <fixes bugid="24563"/>
+ <fixes bugid="24588"/>
</bugs>
<versions>
@@ -99739,6 +99387,7 @@
<versions>
<version ver="5.1.14-ndb-6.1.0"/>
+ <version ver="5.1.15"/>
</versions>
<message>
@@ -105105,9 +104754,10 @@
<versions>
<version ver="5.0.37"/>
+ <version ver="5.0.45"/>
</versions>
- <message>
+ <message ver="5.0.37">
<para>
Added the <literal>SHOW PROFILES</literal> and <literal>SHOW
@@ -105122,6 +104772,15 @@
</message>
+ <message ver="5.0.45">
+
+ <para>
+ Potential memory leaks in <literal>SHOW PROFILE</literal> were
+ eliminated.
+ </para>
+
+ </message>
+
</logentry>
<logentry entrytype="bug">
@@ -106370,6 +106029,7 @@
</bugs>
<versions>
+ <version ver="5.1.14-ndb-6.1.0"/>
<version ver="5.1.15"/>
</versions>
@@ -108370,32 +108030,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- </tags>
-
- <bugs>
- <fixes bugid="24664"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15"/>
- </versions>
-
- <message>
-
- <para>
- Under certain rare circumstances, local checkpoints were not
- performed properly, leading to an inability to restart one or
- more data nodes.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="mysql"/>
<manual type="_cgets()"/>
</tags>
@@ -110949,41 +110583,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="incompatiblechange"/>
- <manual type="ENUM"/>
- <manual type="mysqldump"/>
- </tags>
-
- <bugs>
- <fixes bugid="24660"/>
- </bugs>
-
- <versions>
- <version ver="5.0.36"/>
- <version ver="5.0.37"/>
- </versions>
-
- <message>
-
- <para>
- For <literal>ENUM</literal> columns that had enumeration values
- containing commas, the commas were mapped to 0xff internally.
- However, this rendered the commas indistinguishable from true
- 0xff characters in the values. This no longer occurs. However,
- the fix requires that you dump and reload any tables that have
- <literal>ENUM</literal> columns containing true 0xff in their
- values: Dump the tables using <command>mysqldump</command> with
- the current server before upgrading from a version of MySQL 5.0
- older than 5.0.36 to version 5.0.36 or newer.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="SELECT"/>
</tags>
@@ -113446,20 +113045,21 @@
</bugs>
<versions>
- <version ver="5.0.33"/>
<version ver="5.0.30sp1"/>
<version ver="5.0.32"/>
+ <version ver="5.0.33"/>
+ <version ver="5.1.15"/>
</versions>
<message>
<para>
- In MySQL 5.0.13 and up, <literal>InnoDB</literal> rolls back
- only the last statement on a transaction timeout. A new option,
+ <literal>InnoDB</literal> rolls back only the last statement on
+ a transaction timeout. A new option,
<option>--innodb_rollback_on_timeout</option>, causes
<literal>InnoDB</literal> to abort and roll back the entire
transaction if a transaction timeout occurs (the same behavior
- as before MySQL 5.0.13).
+ as in MySQL 5.0.13 and earlier).
</para>
</message>
@@ -125023,7 +124623,10 @@
</bugs>
<versions>
+ <version ver="5.0.36"/>
+ <version ver="5.0.37"/>
<version ver="5.1.15-ndb-6.1.7"/>
+ <version ver="5.1.16"/>
</versions>
<message>
@@ -126667,32 +126270,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- <manual type="cluster"/>
- </tags>
-
- <bugs>
- <fixes bugid="25239"/>
- </bugs>
-
- <versions>
- <version ver="5.1.15-ndb-6.1.3"/>
- </versions>
-
- <message>
-
- <para>
- A memory allocation failure in the cluster Subscription Manager
- could cause the cluster to crash.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="FLUSH TABLES"/>
<manual type="HANDLER"/>
</tags>
@@ -129046,35 +128623,6 @@
</logentry>
- <logentry entrytype="bug">
-
- <tags>
- <highlight type="clusterapi"/>
- <manual type="cluster"/>
- <manual type="transactions"/>
- </tags>
-
- <bugs>
- <fixes bugid="24949"/>
- </bugs>
-
- <versions>
- <version ver="5.1.14-ndb-6.1.0"/>
- </versions>
-
- <message>
-
- <para>
- When using the <literal>NdbTransaction::execute()</literal>
- method, a very long timeout (greater than 5 minutes) could
- result if the last data node polled was disconnected from the
- cluster.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="feature">
<tags>
@@ -129936,33 +129484,6 @@
</logentry>
- <logentry entrytype="feature">
-
- <tags>
- <highlight type="cluster"/>
- <manual type="ndb_size.pl"/>
- </tags>
-
- <bugs>
- <fixes bugid="24227"/>
- </bugs>
-
- <versions>
- <version ver="5.1.18"/>
- </versions>
-
- <message>
-
- <para>
- When <command>ndb_size.pl</command> calculates a value for a
- given configuration parameter that is less than the default
- value, it now suggests the default value instead.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="bug">
<tags>
@@ -130148,6 +129669,7 @@
<versions>
<version ver="5.1.14-ndb-6.1.0"/>
+ <version ver="5.1.15"/>
</versions>
<message>
@@ -134290,34 +133812,6 @@
</logentry>
- <logentry entrytype="bug">
-
- <tags>
- <manual type="ORDER BY"/>
- <manual type="InnoDB"/>
- </tags>
-
- <bugs>
- <fixes bugid="24778"/>
- </bugs>
-
- <versions>
- <version ver="5.1.17"/>
- </versions>
-
- <message>
-
- <para>
- Adding <literal>ORDER BY</literal> clause to a query on an
- <literal>InnoDB</literal> table could cause the statement to
- return no result if the optimizer chose a covering index that
- enabled it to skip the <literal>ORDER BY</literal>.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="feature">
<tags>
@@ -135261,39 +134755,6 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
- <manual type="TRUNCATE"/>
- </tags>
-
- <bugs>
- <fixes bugid="25296"/>
- <fixes bugid="24667"/>
- </bugs>
-
- <versions>
- <version ver="5.1.18"/>
- </versions>
-
- <message>
-
- <para>
- (Disk Data): Changing a column specification or issuing a
- <literal>TRUNCATE</literal> statement on a Disk Data table
- caused the table to become an in-memory table.
- </para>
-
- <para>
- This fix supersedes an incomplete fix that was made for this
- issue in MySQL 5.1.15.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<manual type="HP-UX"/>
<manual type="InnoDB"/>
<manual type="mysqld"/>
@@ -136219,6 +135680,7 @@
<versions>
<version ver="5.0.36"/>
+ <version ver="5.0.37"/>
<version ver="5.1.16"/>
</versions>
@@ -136227,11 +135689,15 @@
<para>
Using an <literal>INFORMATION_SCHEMA</literal> table with
<literal>ORDER BY</literal> in a subquery could cause a server
- crash. We would like to thank Oren Isacson from Flowgate
- Security Consulting as well as well as Stefan Streichsbier from
- SEC Consult for informing us about this problem.
+ crash.
</para>
+ <para>
+ We would like to thank Oren Isacson of Flowgate Security
+ Consulting and Stefan Streichsbier of SEC Consult for informing
+ us of this problem.
+ </para>
+
</message>
</logentry>
@@ -136671,31 +136137,6 @@
<logentry entrytype="bug">
<tags>
- <manual type="SHOW PROFILE"/>
- </tags>
-
- <bugs>
- <fixes bugid="24795"/>
- </bugs>
-
- <versions>
- <version ver="5.0.45"/>
- </versions>
-
- <message>
-
- <para>
- Potential memory leaks in the <literal>SHOW PROFILE</literal>
- implementation were eliminated.
- </para>
-
- </message>
-
- </logentry>
-
- <logentry entrytype="bug">
-
- <tags>
<highlight type="incompatiblechange"/>
<manual type="db_collation"/>
<manual type="SHOW FUNCTION STATUS"/>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r8713 - trunk/dynamic-docs/changelog | jon | 14 Nov |
