Author: mcbrown
Date: 2007-09-04 09:00:03 +0200 (Tue, 04 Sep 2007)
New Revision: 7641
Log:
Ran remap-note-para.xml on all content
Modified:
trunk/refman-common/news-cluster.xml
trunk/refman-common/news-innodb.xml
Modified: trunk/refman-common/news-cluster.xml
===================================================================
--- trunk/refman-common/news-cluster.xml 2007-09-04 06:57:53 UTC (rev 7640)
+++ trunk/refman-common/news-cluster.xml 2007-09-04 07:00:03 UTC (rev 7641)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 5; 757 bytes
@@ -57,11 +57,12 @@
<title>Changes in MySQL Cluster-5.0.7 (10 June 2005)</title>
- <para>
- <emphasis role="bold">Note</emphasis>: Starting with version
- 5.0.8, changes for MySQL Cluster can be found in the combined
- MySQL Change History.
- </para>
+ <note>
+ <para>
+ Starting with version 5.0.8, changes for MySQL Cluster can be
+ found in the combined MySQL Change History.
+ </para>
+ </note>
<para>
Functionality added or changed:
Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml 2007-09-04 06:57:53 UTC (rev 7640)
+++ trunk/refman-common/news-innodb.xml 2007-09-04 07:00:03 UTC (rev 7641)
Changed blocks: 3, Lines Added: 52, Lines Deleted: 48; 6174 bytes
@@ -232,21 +232,22 @@
<itemizedlist>
<listitem>
- <para>
- <emphasis role="bold">Important:</emphasis> Made internal
- representation of <literal>TIMESTAMP</literal> values in
- <literal>InnoDB</literal> in 4.1 to be the same as in 4.0.
- This difference resulted in incorrect datetime values in
- <literal>TIMESTAMP</literal> columns in
- <literal>InnoDB</literal> tables after an upgrade from 4.0 to
- 4.1. (Bug #4492) <emphasis role="bold">Warning: extra steps
- during upgrade required!</emphasis> This means that if you are
- upgrading from 4.1.x, where x <= 3, to 4.1.4 you should use
- <literal>mysqldump</literal> for saving and then restoring
- your <literal>InnoDB</literal> tables with
- <literal>TIMESTAMP</literal> columns. No conversion is needed
- if you upgrade from 3.23 or 4.0 to 4.1.4 or later.
- </para>
+ <important>
+ <para>
+ Made internal representation of <literal>TIMESTAMP</literal>
+ values in <literal>InnoDB</literal> in 4.1 to be the same as
+ in 4.0. This difference resulted in incorrect datetime
+ values in <literal>TIMESTAMP</literal> columns in
+ <literal>InnoDB</literal> tables after an upgrade from 4.0
+ to 4.1. (Bug #4492) <emphasis role="bold">Warning: extra
+ steps during upgrade required!</emphasis> This means that if
+ you are upgrading from 4.1.x, where x <= 3, to 4.1.4 you
+ should use <literal>mysqldump</literal> for saving and then
+ restoring your <literal>InnoDB</literal> tables with
+ <literal>TIMESTAMP</literal> columns. No conversion is
+ needed if you upgrade from 3.23 or 4.0 to 4.1.4 or later.
+ </para>
+ </important>
</listitem>
<listitem>
@@ -385,29 +386,30 @@
<itemizedlist>
<listitem>
- <para>
- <emphasis role="bold">Important:</emphasis> Starting from
- MySQL 4.1.3, <literal>InnoDB</literal> uses the same character
- set comparison functions as MySQL for
- non-<literal>latin1_swedish_ci</literal> character strings
- that are not <literal>BINARY</literal>. This changes the
- sorting order of space and characters < ASCII(32) in those
- character sets. For <literal>latin1_swedish_ci</literal>
- character strings and <literal>BINARY</literal> strings,
- <literal>InnoDB</literal> uses its own pad-spaces-at-end
- comparison method, which stays unchanged. If you have an
- <literal>InnoDB</literal> table created with MySQL 4.1.2 or
- earlier, with an index on a non-<literal>latin1</literal>
- character set (in the case of 4.1.0 and 4.1.1 with any
- character set)
- <literal>CHAR</literal>/<literal>VARCHAR</literal>/or
- <literal>TEXT</literal> column that is not
- <literal>BINARY</literal> but may contain characters <
- ASCII(32), then you should do <literal>ALTER TABLE</literal>
- or <literal>OPTIMIZE</literal> table on it to
- <emphasis role="bold">regenerate the index, after upgrading to
- MySQL 4.1.3 or later</emphasis>.
- </para>
+ <important>
+ <para>
+ Starting from MySQL 4.1.3, <literal>InnoDB</literal> uses
+ the same character set comparison functions as MySQL for
+ non-<literal>latin1_swedish_ci</literal> character strings
+ that are not <literal>BINARY</literal>. This changes the
+ sorting order of space and characters < ASCII(32) in
+ those character sets. For
+ <literal>latin1_swedish_ci</literal> character strings and
+ <literal>BINARY</literal> strings, <literal>InnoDB</literal>
+ uses its own pad-spaces-at-end comparison method, which
+ stays unchanged. If you have an <literal>InnoDB</literal>
+ table created with MySQL 4.1.2 or earlier, with an index on
+ a non-<literal>latin1</literal> character set (in the case
+ of 4.1.0 and 4.1.1 with any character set)
+ <literal>CHAR</literal>/<literal>VARCHAR</literal>/or
+ <literal>TEXT</literal> column that is not
+ <literal>BINARY</literal> but may contain characters <
+ ASCII(32), then you should do <literal>ALTER TABLE</literal>
+ or <literal>OPTIMIZE</literal> table on it to
+ <emphasis role="bold">regenerate the index, after upgrading
+ to MySQL 4.1.3 or later</emphasis>.
+ </para>
+ </important>
</listitem>
<listitem>
@@ -515,16 +517,18 @@
<title>Changes in MySQL/InnoDB-4.1.2, May 30, 2004</title>
- <para>
- <emphasis role="bold">NOTE</emphasis>: CRITICAL BUG in 4.1.2 if
- you specify <literal>innodb_file_per_table</literal> in
- <filename>my.cnf</filename> on Unix. In crash recovery InnoDB
- skips the crash recovery for all <filename>.ibd</filename> files
- and those tables become CORRUPT! The symptom is a message
- <literal>Unable to lock ...ibd with lock 1, error: 9: fcntl: Bad
- file descriptor</literal> in the <filename>.err</filename> log in
- crash recovery.
- </para>
+ <note>
+ <para>
+ CRITICAL BUG in 4.1.2 if you specify
+ <literal>innodb_file_per_table</literal> in
+ <filename>my.cnf</filename> on Unix. In crash recovery InnoDB
+ skips the crash recovery for all <filename>.ibd</filename> files
+ and those tables become CORRUPT! The symptom is a message
+ <literal>Unable to lock ...ibd with lock 1, error: 9: fcntl: Bad
+ file descriptor</literal> in the <filename>.err</filename> log
+ in crash recovery.
+ </para>
+ </note>
<para>
Functionality added or changed:
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r7641 - trunk/refman-common | mcbrown | 4 Sep |
