Author: jstephens
Date: 2008-05-31 10:38:04 +0200 (Sat, 31 May 2008)
New Revision: 10871
Log:
Fixed a bunch of little glitches in changelog entries encountered whilst
trying to run down an old bug report.
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/dynamic-docs/changelog/mysqld.xml
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2008-05-31 02:32:38 UTC (rev 10870)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2008-05-31 08:38:04 UTC (rev 10871)
Changed blocks: 4, Lines Added: 9, Lines Deleted: 8; 2077 bytes
@@ -3395,7 +3395,7 @@
<para>
Dropping a tablespace for the <literal>Falcon</literal> storage
- engine when the specified tablespace does not exist would
+ engine when the specified tablespace did not exist would
silently succeed, instead of generating a suitable error
message.
</para>
@@ -9065,8 +9065,8 @@
<para>
Repeatedly creating and dropping <literal>Falcon</literal>
- tablespaces would fail because a dropped tablespace would not be
- dropped before the new tablespace file was created.
+ tablespaces failed because the old tablespace was not dropped
+ before the new tablespace file was created.
</para>
</message>
@@ -9147,10 +9147,11 @@
<para>
When accessing the statistics in
<literal>INFORMATION_SCHEMA.FALCON_DATABASE_IO</literal>, the
- information would related only to the Falcon database, not user
+ information related only to the Falcon database, and not to user
tablespaces. The output has been updated to report on all
- tablespaces, and the column title has been changed to reflect
- the fact that the statistics are now reported by tablespace, not
+ tablespaces, and the <literal>DATABASE</literal> column has been
+ renamed to <literal>TABLESPACE</literal> to reflect the fact
+ that these statistics are now reported by tablespace, not by
database.
</para>
@@ -9257,8 +9258,8 @@
<para>
Creating a new table or dropping a database on a newly created
- database or tablespace where the <literal>Falcon</literal>
- engine was used would raise an error.
+ <literal>Falcon</literal> database or tablespace raised an
+ error.
</para>
</message>
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2008-05-31 02:32:38 UTC (rev 10870)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2008-05-31 08:38:04 UTC (rev 10871)
Changed blocks: 50, Lines Added: 116, Lines Deleted: 137; 18765 bytes
@@ -1387,7 +1387,7 @@
<para>
When dropping Falcon tablespaces the associated tablespace file
- would not be deleted.
+ was not deleted.
</para>
</message>
@@ -1412,8 +1412,8 @@
<para>
Dropping a tablespace and specifying an engine type that does
- not support tablespaces would report a warning. The response has
- now been updated to report an error.
+ not support tablespaces reported a warning. The response has now
+ been updated to report an error.
</para>
</message>
@@ -1439,9 +1439,9 @@
<para>
When creating a <literal>TABLESPACE</literal> that uses the same
- name as an existing <literal>TABLESPACE</literal>, Falcon would
- return <literal>Unknown error -103</literal>. MySQL will now
- return an error stating that the specified tablespace already
+ name as an existing <literal>TABLESPACE</literal>, Falcon
+ returned <literal>Unknown error -103</literal>. MySQL now
+ returns an error stating that the specified tablespace already
exists.
</para>
@@ -2346,11 +2346,10 @@
<message>
<para>
- Creating a tablespace with a unique name but using the same
- datafile as an existing tablespace results in the
- re-initialization of the tablespace and the loss of the data
- contained in it. Falcon will now report an error if you the
- datafile already exists.
+ Creating a tablespace with a unique name but using the same data
+ file as an existing tablespace results in the re-initialization
+ of the tablespace and the loss of the data contained in it.
+ Falcon now reports an error if the data file already exists.
</para>
</message>
@@ -2871,8 +2870,7 @@
<message>
<para>
- Renaming tables to or from Falcon tablespaces would raise an
- error.
+ Renaming tables to or from Falcon tablespaces raised an error.
</para>
</message>
@@ -11938,7 +11936,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
<manual type="cluster"/>
<manual type="initial"/>
</tags>
@@ -11954,11 +11952,11 @@
<message>
<para>
- (Disk Data): Creating a tablespace and log file group, then
- attempting to restart the cluster without using the
- <option>--initial</option> option and without having created any
- Disk Data tables could cause a forced shutdown of the cluster
- and raise a configuration error.
+ Creating a tablespace and log file group, then attempting to
+ restart the cluster without using the <option>--initial</option>
+ option and without having created any Disk Data tables could
+ cause a forced shutdown of the cluster and raise a configuration
+ error.
</para>
</message>
@@ -18719,8 +18717,8 @@
<message>
<para>
- The <filename>mysql.server</filename> script contained incorrect
- path for the <literal>libexec</literal> directory.
+ The <filename>mysql.server</filename> script contained an
+ incorrect path for the <literal>libexec</literal> directory.
</para>
</message>
@@ -57585,9 +57583,10 @@
<message>
<para>
- InnoDB: Return a sensible error code from <literal>DISCARD
- TABLESPACE</literal> if it fails because the table is referenced
- by a <literal>FOREIGN KEY</literal>.
+ <literal>InnoDB</literal>: When <literal>DISCARD
+ TABLESPACE</literal> failed because the table was referenced by
+ a foreign key, the error code returned did not indicate that
+ this was the case.
</para>
</message>
@@ -59466,7 +59465,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -59480,9 +59479,9 @@
<message>
<para>
- (Disk Data): In the event of an aborted multiple update, the
- space in the Disk Data log buffer to be freed as a result was
- actually freed twice, which could eventually lead to a crash.
+ In the event of an aborted multiple update, the space in the
+ Disk Data log buffer to be freed as a result was actually freed
+ twice, which could eventually lead to a crash.
</para>
</message>
@@ -62735,7 +62734,7 @@
<message>
<para>
- <literal>InnoDB</literal>: Added configuration option
+ <literal>InnoDB</literal>: Added the configuration option
<literal>innodb_autoextend_increment</literal> for setting the
size in megabytes by which <literal>InnoDB</literal> tablespaces
are extended when they become full. The default value is 8,
@@ -64268,9 +64267,9 @@
<message>
<para>
- InnoDB: Fixed a bug that prevented <literal>ALTER TABLE
- <replaceable>t</replaceable> DISCARD TABLESPACE</literal> from
- working.
+ <literal>InnoDB</literal>: <literal>ALTER TABLE
+ <replaceable>t</replaceable> DISCARD TABLESPACE</literal> did
+ not work correctly.
</para>
</message>
@@ -66013,7 +66012,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -66027,8 +66026,7 @@
<message>
<para>
- (Disk Data): It was not possible to create more than 9
- tablespaces.
+ It was not possible to create more than 9 tablespaces.
</para>
</message>
@@ -72671,7 +72669,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -72685,8 +72683,8 @@
<message>
<para>
- (Disk Data): Creating an excessive number of Disk Data tables
- (1000 or more) could cause data nodes to fail.
+ Creating an excessive number of Disk Data tables (1000 or more)
+ could cause data nodes to fail.
</para>
</message>
@@ -73082,7 +73080,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -73096,9 +73094,9 @@
<message>
<para>
- (Disk Data): A data file created on one tablespace could be
- dropped using <literal>ALTER TABLESPACE ... DROP
- DATAFILE</literal> on a different tablespace.
+ A data file created for one tablespace could be dropped using
+ <literal>ALTER TABLESPACE ... DROP DATAFILE</literal> using a
+ different tablespace.
</para>
</message>
@@ -76608,7 +76606,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
<manual type="ALTER TABLESPACE"/>
</tags>
@@ -76623,17 +76621,17 @@
<message>
<para>
- (Disk Data): It was possible to drop the last remaining datafile
- in a tablespace (using an <literal>ALTER TABLESPACE</literal>
- statement), even though there was still an empty table using the
- tablespace.
+ It was possible to drop the last remaining datafile in a
+ tablespace using <literal>ALTER TABLESPACE</literal>, even when
+ there was still an empty table using the tablespace.
</para>
- <para>
- It should be noted that the datafile could be not dropped if the
- table still contained any rows, so this bug involved no loss of
- data.
- </para>
+ <note>
+ <para>
+ The datafile could be not dropped if the table still contained
+ any rows, so this bug involved no loss of data.
+ </para>
+ </note>
</message>
@@ -77937,7 +77935,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -77951,9 +77949,8 @@
<message>
<para>
- (Disk Data): Tablespaces created using parameters with
- relatively low values (< 10 MB) produced filesizes much
- smaller than expected.
+ Tablespaces created using parameters with relatively low values
+ (10 MB or less) produced filesizes much smaller than expected.
</para>
</message>
@@ -80415,7 +80412,7 @@
<para>
If you upgrade to MySQL 4.1.1 or higher, it is difficult to
- downgrade back to 4.0 or 4.1.0! That is because, for earlier
+ downgrade back to 4.0 or 4.1.0. That is because, for earlier
versions, <literal>InnoDB</literal> is not aware of multiple
tablespaces.
</para>
@@ -94526,7 +94523,7 @@
<logentry entrytype="feature">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -94540,8 +94537,8 @@
<message>
<para>
- (Disk Data): You can now have only one log file group at any one
- time. See <xref linkend="create-logfile-group"/>.
+ You can now have only one log file group at any one time. See
+ <xref linkend="create-logfile-group"/>.
</para>
</message>
@@ -95193,13 +95190,13 @@
<message>
<para>
- <literal>InnoDB</literal>: Fix a problem in crash recovery of
- <filename>.ibd</filename> files on Windows if the user used
- <literal>lower_case_table_names=0</literal> or
- <literal>2</literal>; the directory scan in crash recovery
- forgot to put all paths to lower case, so that the tablespace
- name would be consistent with the internal data dictionary of
- InnoDB.
+ <literal>InnoDB</literal>: Crash recovery of
+ <filename>.ibd</filename> files on Windows did not work
+ correctly if <literal>lower_case_table_names=0</literal>or
+ <literal>lower_case_table_names=2</literal> had been used; the
+ directory scan used in crash recovery failed to force all paths
+ to lower case, so that the tablespace name was consistent with
+ the <literal>InnoDB</literal> internal data dictionary.
</para>
</message>
@@ -97591,7 +97588,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -97605,8 +97602,8 @@
<message>
<para>
- (Disk Data): Errors could occur when dropping a data file during
- a node local checkpoint.
+ Errors could occur when dropping a data file during a node local
+ checkpoint.
</para>
</message>
@@ -110883,7 +110880,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -110897,9 +110894,9 @@
<message>
<para>
- (Disk Data): Trying to create a Disk Data table using a
- nonexistent tablespace or trying to drop a nonexistent data file
- from a tablespace produced an uninformative error message.
+ Trying to create a Disk Data table using a nonexistent
+ tablespace or to drop a nonexistent data file from a tablespace
+ produced an uninformative error message.
</para>
</message>
@@ -111327,7 +111324,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -111341,8 +111338,8 @@
<message>
<para>
- (Disk Data): Running a large nbumber of scans on Disk Data could
- cause subsequent scans to perform poorly.
+ Running a large number of scans on Disk Data could cause
+ subsequent scans to perform poorly.
</para>
</message>
@@ -116762,8 +116759,9 @@
<para>
It was possible to execute a statement for creating a Disk Data
table that referred to a nonexistent tablespace, in which case
- the table was an in-memory <literal>NDB</literal> table. Such a
- statement instead now fails with an appropriate error message.
+ the table created was actually an in-memory
+ <literal>NDB</literal> table. Such a statement now fails
+ instead, with an appropriate error message.
</para>
</message>
@@ -119332,30 +119330,6 @@
</logentry>
- <logentry entrytype="feature">
-
- <tags>
- <highlight type="importantchange"/>
- <manual type="InnoDB"/>
- </tags>
-
- <versions>
- <version ver="4.1.1"/>
- </versions>
-
- <message>
-
- <para>
- If you upgrade to <literal>InnoDB</literal>-4.1.1 or higher, you
- cannot downgrade to a version lower than 4.1.1 any more! That is
- because earlier versions of <literal>InnoDB</literal> are not
- aware of multiple tablespaces.
- </para>
-
- </message>
-
- </logentry>
-
<logentry entrytype="bug">
<tags>
@@ -119375,7 +119349,8 @@
<para>
<literal>SHOW CREATE TABLE</literal> produced extraneous spaces
- after the <literal>PRIMARY KEY</literal> keywords.
+ following the keywords <quote><literal>PRIMARY
+ KEY</literal></quote>.
</para>
</message>
@@ -120174,8 +120149,9 @@
<command>mysqldump</command> did not add version-specific
comments around <literal>WITH PARSER</literal> and
<literal>TABLESPACE ... STORAGE DISK</literal> clauses for
- <literal>CREATE TABLE</literal> statements, causing the dump
- file to fail when loaded into older servers.
+ <literal>CREATE TABLE</literal> statements, causing dump files
+ from servers where these features were in use to fail when
+ loaded into older servers.
</para>
</message>
@@ -120200,8 +120176,8 @@
<message>
<para>
- The Cluster table handler did not set bits in null bytes
- correctly.
+ The <literal>NDBCLUSTER</literal> table handler did not set bits
+ in null bytes correctly.
</para>
</message>
@@ -120278,7 +120254,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
<manual type="CREATE TABLESPACE"/>
<manual type="CREATE LOGFILE GROUP"/>
</tags>
@@ -120294,10 +120270,9 @@
<message>
<para>
- (Disk Data): The failure of a <literal>CREATE
- TABLESPACE</literal> or <literal>CREATE LOGFILE GROUP</literal>
- statement did not revert all changes made prior to the point of
- failure.
+ The failure of a <literal>CREATE TABLESPACE</literal> or
+ <literal>CREATE LOGFILE GROUP</literal> statement did not revert
+ all changes made prior to the point of failure.
</para>
</message>
@@ -120307,8 +120282,8 @@
<logentry entrytype="bug">
<tags>
+ <highlight type="replication"/>
<manual type="LOAD DATA INFILE"/>
- <manual type="replication"/>
</tags>
<bugs>
@@ -120322,7 +120297,7 @@
<message>
<para>
- If, on a replication master a <literal>LOAD DATA
+ If, on a replication master, a <literal>LOAD DATA
INFILE</literal> operation was interrupted (by, for example, an
integrity constraint violation or killed connection), the slave
skipped the <literal>LOAD DATA INFILE</literal> entirely, thus
@@ -126697,7 +126672,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -126711,9 +126686,9 @@
<message>
<para>
- (Disk Data): <literal>ALTER TABLE ... ADD COLUMN ...</literal>
- on a Disk Data table moved data for existing non-indexed columns
- from the tablespace into memory.
+ <literal>ALTER TABLE ... ADD COLUMN ...</literal> on a Disk Data
+ table moved data for existing non-indexed columns from the
+ tablespace into memory.
</para>
</message>
@@ -126733,8 +126708,8 @@
<message>
<para>
- For view renaming, the table name to filename encoding was not
- performed.
+ For renaming of views, encoding of table name to filenames was
+ not performed.
</para>
</message>
@@ -127429,11 +127404,12 @@
<message>
<para>
- <literal>InnoDB</literal>: Commit after every 10,000 copied rows
- when executing <literal>ALTER TABLE</literal>, <literal>CREATE
- INDEX</literal>, <literal>DROP INDEX</literal> or
- <literal>OPTIMIZE TABLE</literal>. This makes it much faster to
- recover from an aborted operation.
+ <literal>InnoDB</literal>: A commit is now performed after every
+ 10,000 copied rows when executing <literal>ALTER
+ TABLE</literal>, <literal>CREATE INDEX</literal>, <literal>DROP
+ INDEX</literal> or <literal>OPTIMIZE TABLE</literal>. This makes
+ recovery from an aborted operations of these types much faster
+ than previous to this change.
</para>
</message>
@@ -130518,7 +130494,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
</tags>
<bugs>
@@ -130532,8 +130508,8 @@
<message>
<para>
- (Disk Data): Creating an excessive number of data files for a
- single tablespace caused data nodes to crash.
+ Creating an excessive number of data files for a single
+ tablespace caused data nodes to crash.
</para>
</message>
@@ -134739,7 +134715,7 @@
<logentry entrytype="bug">
<tags>
- <highlight type="cluster"/>
+ <highlight type="diskdata"/>
<manual type="UNDO_BUFFER_SIZE"/>
<manual type="mysqldump"/>
<manual type="INITIAL_SIZE"/>
@@ -134756,15 +134732,18 @@
<message>
<para>
- (Disk Data): <command>mysqldump</command> did not back up
- tablespace or log file group information for Disk Data tables
- correctly. (Specifically, <literal>UNDO_BUFFER_SIZE</literal>
- and <literal>INITIAL_SIZE</literal> values were misreported.)
- Trying to restore from such a backup would produce error 1296
- (<errortext>Got error 1504 'Out of logbuffer memory' from
- NDB</errortext>).
+ <command>mysqldump</command> did not back up tablespace or log
+ file group information for Disk Data tables correctly.
</para>
+ <para>
+ Specifically, <literal>UNDO_BUFFER_SIZE</literal> and
+ <literal>INITIAL_SIZE</literal> values were misreported. This
+ meant that trying to restore from such a backup would produce
+ error 1296: <errortext>Got error 1504 'Out of logbuffer memory'
+ from NDB</errortext>.
+ </para>
+
</message>
</logentry>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10871 - trunk/dynamic-docs/changelog | jon | 31 May |
