Author: paul
Date: 2008-05-20 18:57:24 +0200 (Tue, 20 May 2008)
New Revision: 10789
Log:
r31563@frost: paul | 2008-05-20 11:56:08 -0500
Document bugfix:
Bug#36055: mysql_upgrade doesn't really 'upgrade' tables
Modified:
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/it/refman-5.1/sql-syntax.xml
trunk/pt/refman-5.1/sql-syntax.xml
trunk/refman-4.1/sql-syntax.xml
trunk/refman-5.0/sql-syntax.xml
trunk/refman-5.1/sql-syntax.xml
trunk/refman-6.0/sql-syntax.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31561
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31325
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:31563
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31325
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 1, Lines Added: 88, Lines Deleted: 0; 3464 bytes
@@ -19562,4 +19562,92 @@
</logentry>
+ <logentry entrytype="feature">
+
+ <tags>
+ <highlight type="importantchange"/>
+ <manual type="CHECK TABLE"/>
+ <manual type="FOR UPGRADE"/>
+ <manual type="REPAIR TABLE"/>
+ <manual type="USE_FRM"/>
+ <manual type="mysqlcheck"/>
+ <manual type="mysql_upgrade"/>
+ </tags>
+
+ <bugs>
+ <fixes bugid="36055"/>
+ </bugs>
+
+ <versions>
+ <version ver="5.0.62"/>
+ <version ver="5.1.25"/>
+ </versions>
+
+ <message>
+
+ <para>
+ Some changes were made to <literal>CHECK TABLE ... FOR
+ UPGRADE</literal> and <literal>REPAIR TABLE</literal> with
+ respect to detection and handling of tables with incompatible
+ <filename>.frm</filename> files (files created with a different
+ version of the MySQL server). These changes also affect
+ <command>mysqlcheck</command> because that program uses
+ <literal>CHECK TABLE</literal> and <literal>REPAIR</literal>
+ table, and thus also <command>mysql_upgrade</command> because
+ that program invokes <command>mysqlcheck</command>.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ If your table was created by a different version of the
+ MySQL server than the one you are currently running,
+ <literal>CHECK TABLE ... FOR UPGRADE</literal> indicates
+ that the table has an <filename>.frm</filename> file with an
+ incompatible version. In this case, the result set returned
+ by <literal>CHECK TABLE</literal> contains a line with a
+ <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Table upgrade required. Please do "REPAIR
+ TABLE `<replaceable>tbl_name</replaceable>`" to fix
+ it!</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>REPAIR TABLE</literal> without
+ <literal>USE_FRM</literal> upgrades the
+ <filename>.frm</filename> file to the current version.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If you use <literal>REPAIR TABLE ...USE_FRM</literal> and
+ your table was created by a different version of the MySQL
+ server than the one you are currently running,
+ <literal>REPAIR TABLE</literal> will not attempt to repair
+ the table. In this case, the result set returned by
+ <literal>REPAIR TABLE</literal> contains a line with a
+ <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Failed repairing incompatible .FRM
+ file</literal>.
+ </para>
+ <para>
+ Previously, use of <literal>REPAIR TABLE
+ ...USE_FRM</literal> with a table created by a different
+ version of the MySQL server risked the loss of all rows in
+ the table.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
</changelog>
Modified: trunk/it/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/it/refman-5.1/sql-syntax.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/it/refman-5.1/sql-syntax.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 6, Lines Added: 54, Lines Deleted: 22; 6320 bytes
@@ -5669,9 +5669,9 @@
For <literal>NDB</literal> tables, beginning with MySQL
5.1.22-ndb-6.2.5 and MySQL 5.1.22-ndb-6.3.3, you can drop
indexes online, using the <literal>ONLINE</literal> keyword.
- This means that the <literal>DROP</literal> operation does
- not require the affected table to be copied (and so the table is
- not locked). You can also drop indexes offline (which causes the
+ This means that the <literal>DROP</literal> operation does not
+ require the affected table to be copied (and so the table is not
+ locked). You can also drop indexes offline (which causes the
table to be locked) using <literal>OFFLINE</literal>. The rules
and limitations governing online <literal>DROP ONLINE
INDEX</literal> and <literal>ADD OFFLINE INDEX</literal> are the
@@ -11573,8 +11573,8 @@
</para>
<para>
- When index hints are processed, they are collected in a
- single list by type (<literal>USE</literal>,
+ When index hints are processed, they are collected in a single
+ list by type (<literal>USE</literal>,
<literal>FORCE</literal>, <literal>IGNORE</literal>) and by
scope (<literal>FOR JOIN</literal>, <literal>FOR ORDER
BY</literal>, <literal>FOR GROUP BY</literal>). For example:
@@ -13466,8 +13466,8 @@
</para>
<para>
- The count of rows affected by <literal>TRUNCATE
- TABLE</literal> is accurate only when it is mapped to a
+ The count of rows affected by <literal>TRUNCATE TABLE</literal>
+ is accurate only when it is mapped to a
<literal>DELETE</literal> statement.
</para>
@@ -15155,14 +15155,13 @@
lock and released it. A request for a <literal>LOW_PRIORITY
WRITE</literal> lock, by contrast, allows subsequent
<literal>READ</literal> lock requests by other threads to be
- satisfied first if they occur while the
- <literal>LOW_PRIORITY WRITE</literal> request is waiting. You
- should use <literal>LOW_PRIORITY WRITE</literal> locks only if
- you are sure that eventually there will be a time when no
- threads have a <literal>READ</literal> lock. For
- <literal>InnoDB</literal> tables in transactional mode
- (autocommit = 0), a waiting <literal>LOW_PRIORITY
- WRITE</literal> lock acts like a regular
+ satisfied first if they occur while the <literal>LOW_PRIORITY
+ WRITE</literal> request is waiting. You should use
+ <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
+ that eventually there will be a time when no threads have a
+ <literal>READ</literal> lock. For <literal>InnoDB</literal>
+ tables in transactional mode (autocommit = 0), a waiting
+ <literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
<literal>READ</literal> lock requests to wait.)
</para>
@@ -18294,6 +18293,23 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ As of MySQL 5.1.25, if your table was created by a
+ different version of the MySQL server than the one you are
+ currently running, <literal>FOR UPGRADE</literal>
+ indicates that the table has an <filename>.frm</filename>
+ file with an incompatible version. In this case, the
+ result set returned by <literal>CHECK TABLE</literal>
+ contains a line with a <literal>Msg_type</literal> value
+ of <literal>error</literal> and a
+ <literal>Msg_text</literal> value of <literal>Table
+ upgrade required. Please do "REPAIR TABLE
+ `<replaceable>tbl_name</replaceable>`" to fix
+ it!</literal>
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -18909,19 +18925,35 @@
to see whether an upgrade is required and if it is necessary
performs the upgrade, following the same rules as
<literal>CHECK TABLE ... FOR UPGRADE</literal>. See
- <xref linkend="check-table"/>, for more information.
+ <xref linkend="check-table"/>, for more information. As of
+ MySQL 5.1.25, <literal>REPAIR TABLE</literal> without
+ <literal>USE_FRM</literal> upgrades the
+ <filename>.frm</filename> file to the current version.
</para>
<caution>
<para>
- Do not use <literal>USE_FRM</literal> if your table was
- created by a different version of the MySQL server than the
- one you are currently running. Doing so risks the loss of
- all rows in the table. It is particularly dangerous to use
- <literal>USE_FRM</literal> after the server returns this
- message:
+ As of MySQL 5.1.25, if you use <literal>USE_FRM</literal>
+ and your table was created by a different version of the
+ MySQL server than the one you are currently running,
+ <literal>REPAIR TABLE</literal> will not attempt to repair
+ the table. In this case, the result set returned by
+ <literal>REPAIR TABLE</literal> contains a line with a
+ <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Failed repairing incompatible .FRM
+ file</literal>.
</para>
+ <para>
+ Prior to MySQL 5.1.25, <emphasis>do not use</emphasis>
+ <literal>USE_FRM</literal> if your table was created by a
+ different version of the MySQL server. Doing so risks the
+ loss of all rows in the table. It is particularly dangerous
+ to use <literal>USE_FRM</literal> after the server returns
+ this message:
+ </para>
+
<programlisting>
Table upgrade required. Please do
"REPAIR TABLE `<replaceable>tbl_name</replaceable>`" to fix it!
Modified: trunk/pt/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/pt/refman-5.1/sql-syntax.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/pt/refman-5.1/sql-syntax.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 6, Lines Added: 54, Lines Deleted: 22; 6320 bytes
@@ -5669,9 +5669,9 @@
For <literal>NDB</literal> tables, beginning with MySQL
5.1.22-ndb-6.2.5 and MySQL 5.1.22-ndb-6.3.3, you can drop
indexes online, using the <literal>ONLINE</literal> keyword.
- This means that the <literal>DROP</literal> operation does
- not require the affected table to be copied (and so the table is
- not locked). You can also drop indexes offline (which causes the
+ This means that the <literal>DROP</literal> operation does not
+ require the affected table to be copied (and so the table is not
+ locked). You can also drop indexes offline (which causes the
table to be locked) using <literal>OFFLINE</literal>. The rules
and limitations governing online <literal>DROP ONLINE
INDEX</literal> and <literal>ADD OFFLINE INDEX</literal> are the
@@ -11573,8 +11573,8 @@
</para>
<para>
- When index hints are processed, they are collected in a
- single list by type (<literal>USE</literal>,
+ When index hints are processed, they are collected in a single
+ list by type (<literal>USE</literal>,
<literal>FORCE</literal>, <literal>IGNORE</literal>) and by
scope (<literal>FOR JOIN</literal>, <literal>FOR ORDER
BY</literal>, <literal>FOR GROUP BY</literal>). For example:
@@ -13466,8 +13466,8 @@
</para>
<para>
- The count of rows affected by <literal>TRUNCATE
- TABLE</literal> is accurate only when it is mapped to a
+ The count of rows affected by <literal>TRUNCATE TABLE</literal>
+ is accurate only when it is mapped to a
<literal>DELETE</literal> statement.
</para>
@@ -15155,14 +15155,13 @@
lock and released it. A request for a <literal>LOW_PRIORITY
WRITE</literal> lock, by contrast, allows subsequent
<literal>READ</literal> lock requests by other threads to be
- satisfied first if they occur while the
- <literal>LOW_PRIORITY WRITE</literal> request is waiting. You
- should use <literal>LOW_PRIORITY WRITE</literal> locks only if
- you are sure that eventually there will be a time when no
- threads have a <literal>READ</literal> lock. For
- <literal>InnoDB</literal> tables in transactional mode
- (autocommit = 0), a waiting <literal>LOW_PRIORITY
- WRITE</literal> lock acts like a regular
+ satisfied first if they occur while the <literal>LOW_PRIORITY
+ WRITE</literal> request is waiting. You should use
+ <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
+ that eventually there will be a time when no threads have a
+ <literal>READ</literal> lock. For <literal>InnoDB</literal>
+ tables in transactional mode (autocommit = 0), a waiting
+ <literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
<literal>READ</literal> lock requests to wait.)
</para>
@@ -18294,6 +18293,23 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ As of MySQL 5.1.25, if your table was created by a
+ different version of the MySQL server than the one you are
+ currently running, <literal>FOR UPGRADE</literal>
+ indicates that the table has an <filename>.frm</filename>
+ file with an incompatible version. In this case, the
+ result set returned by <literal>CHECK TABLE</literal>
+ contains a line with a <literal>Msg_type</literal> value
+ of <literal>error</literal> and a
+ <literal>Msg_text</literal> value of <literal>Table
+ upgrade required. Please do "REPAIR TABLE
+ `<replaceable>tbl_name</replaceable>`" to fix
+ it!</literal>
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -18909,19 +18925,35 @@
to see whether an upgrade is required and if it is necessary
performs the upgrade, following the same rules as
<literal>CHECK TABLE ... FOR UPGRADE</literal>. See
- <xref linkend="check-table"/>, for more information.
+ <xref linkend="check-table"/>, for more information. As of
+ MySQL 5.1.25, <literal>REPAIR TABLE</literal> without
+ <literal>USE_FRM</literal> upgrades the
+ <filename>.frm</filename> file to the current version.
</para>
<caution>
<para>
- Do not use <literal>USE_FRM</literal> if your table was
- created by a different version of the MySQL server than the
- one you are currently running. Doing so risks the loss of
- all rows in the table. It is particularly dangerous to use
- <literal>USE_FRM</literal> after the server returns this
- message:
+ As of MySQL 5.1.25, if you use <literal>USE_FRM</literal>
+ and your table was created by a different version of the
+ MySQL server than the one you are currently running,
+ <literal>REPAIR TABLE</literal> will not attempt to repair
+ the table. In this case, the result set returned by
+ <literal>REPAIR TABLE</literal> contains a line with a
+ <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Failed repairing incompatible .FRM
+ file</literal>.
</para>
+ <para>
+ Prior to MySQL 5.1.25, <emphasis>do not use</emphasis>
+ <literal>USE_FRM</literal> if your table was created by a
+ different version of the MySQL server. Doing so risks the
+ loss of all rows in the table. It is particularly dangerous
+ to use <literal>USE_FRM</literal> after the server returns
+ this message:
+ </para>
+
<programlisting>
Table upgrade required. Please do
"REPAIR TABLE `<replaceable>tbl_name</replaceable>`" to fix it!
Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/refman-4.1/sql-syntax.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 2, Lines Added: 13, Lines Deleted: 14; 2419 bytes
@@ -11651,14 +11651,13 @@
lock and released it. A request for a <literal>LOW_PRIORITY
WRITE</literal> lock, by contrast, allows subsequent
<literal>READ</literal> lock requests by other threads to be
- satisfied first if they occur while the
- <literal>LOW_PRIORITY WRITE</literal> request is waiting. You
- should use <literal>LOW_PRIORITY WRITE</literal> locks only if
- you are sure that eventually there will be a time when no
- threads have a <literal>READ</literal> lock. For
- <literal>InnoDB</literal> tables in transactional mode
- (autocommit = 0), a waiting <literal>LOW_PRIORITY
- WRITE</literal> lock acts like a regular
+ satisfied first if they occur while the <literal>LOW_PRIORITY
+ WRITE</literal> request is waiting. You should use
+ <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
+ that eventually there will be a time when no threads have a
+ <literal>READ</literal> lock. For <literal>InnoDB</literal>
+ tables in transactional mode (autocommit = 0), a waiting
+ <literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
<literal>READ</literal> lock requests to wait.)
</para>
@@ -14357,12 +14356,12 @@
<caution>
<para>
- Do not use <literal>USE_FRM</literal> if your table was
- created by a different version of the MySQL server than the
- one you are currently running. Doing so risks the loss of
- all rows in the table. It is particularly dangerous to use
- <literal>USE_FRM</literal> after the server returns this
- message:
+ <emphasis>Do not use</emphasis> <literal>USE_FRM</literal>
+ if your table was created by a different version of the
+ MySQL server than the one you are currently running. Doing
+ so risks the loss of all rows in the table. It is
+ particularly dangerous to use <literal>USE_FRM</literal>
+ after the server returns this message:
</para>
<programlisting>
Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/refman-5.0/sql-syntax.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 4, Lines Added: 49, Lines Deleted: 17; 4955 bytes
@@ -10901,8 +10901,8 @@
</para>
<para>
- The count of rows affected by <literal>TRUNCATE
- TABLE</literal> is accurate only when it is mapped to a
+ The count of rows affected by <literal>TRUNCATE TABLE</literal>
+ is accurate only when it is mapped to a
<literal>DELETE</literal> statement.
</para>
@@ -12554,14 +12554,13 @@
lock and released it. A request for a <literal>LOW_PRIORITY
WRITE</literal> lock, by contrast, allows subsequent
<literal>READ</literal> lock requests by other threads to be
- satisfied first if they occur while the
- <literal>LOW_PRIORITY WRITE</literal> request is waiting. You
- should use <literal>LOW_PRIORITY WRITE</literal> locks only if
- you are sure that eventually there will be a time when no
- threads have a <literal>READ</literal> lock. For
- <literal>InnoDB</literal> tables in transactional mode
- (autocommit = 0), a waiting <literal>LOW_PRIORITY
- WRITE</literal> lock acts like a regular
+ satisfied first if they occur while the <literal>LOW_PRIORITY
+ WRITE</literal> request is waiting. You should use
+ <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
+ that eventually there will be a time when no threads have a
+ <literal>READ</literal> lock. For <literal>InnoDB</literal>
+ tables in transactional mode (autocommit = 0), a waiting
+ <literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
<literal>READ</literal> lock requests to wait.)
</para>
@@ -15708,6 +15707,23 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ As of MySQL 5.0.62, if your table was created by a
+ different version of the MySQL server than the one you are
+ currently running, <literal>FOR UPGRADE</literal>
+ indicates that the table has an <filename>.frm</filename>
+ file with an incompatible version. In this case, the
+ result set returned by <literal>CHECK TABLE</literal>
+ contains a line with a <literal>Msg_type</literal> value
+ of <literal>error</literal> and a
+ <literal>Msg_text</literal> value of <literal>Table
+ upgrade required. Please do "REPAIR TABLE
+ `<replaceable>tbl_name</replaceable>`" to fix
+ it!</literal>
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -16301,19 +16317,35 @@
to see whether an upgrade is required and if it is necessary
performs the upgrade, following the same rules as
<literal>CHECK TABLE ... FOR UPGRADE</literal>. See
- <xref linkend="check-table"/>, for more information.
+ <xref linkend="check-table"/>, for more information. As of
+ MySQL 5.0.62, <literal>REPAIR TABLE</literal> without
+ <literal>USE_FRM</literal> upgrades the
+ <filename>.frm</filename> file to the current version.
</para>
<caution>
<para>
- Do not use <literal>USE_FRM</literal> if your table was
- created by a different version of the MySQL server than the
- one you are currently running. Doing so risks the loss of
- all rows in the table. It is particularly dangerous to use
- <literal>USE_FRM</literal> after the server returns this
- message:
+ As of MySQL 5.0.62, if you use <literal>USE_FRM</literal>
+ and your table was created by a different version of the
+ MySQL server than the one you are currently running,
+ <literal>REPAIR TABLE</literal> will not attempt to repair
+ the table. In this case, the result set returned by
+ <literal>REPAIR TABLE</literal> contains a line with a
+ <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Failed repairing incompatible .FRM
+ file</literal>.
</para>
+ <para>
+ Prior to MySQL 5.0.62, <emphasis>do not use</emphasis>
+ <literal>USE_FRM</literal> if your table was created by a
+ different version of the MySQL server. Doing so risks the
+ loss of all rows in the table. It is particularly dangerous
+ to use <literal>USE_FRM</literal> after the server returns
+ this message:
+ </para>
+
<programlisting>
Table upgrade required. Please do
"REPAIR TABLE `<replaceable>tbl_name</replaceable>`" to fix it!
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/refman-5.1/sql-syntax.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 6, Lines Added: 54, Lines Deleted: 22; 6311 bytes
@@ -5669,9 +5669,9 @@
For <literal>NDB</literal> tables, beginning with MySQL
5.1.22-ndb-6.2.5 and MySQL 5.1.22-ndb-6.3.3, you can drop
indexes online, using the <literal>ONLINE</literal> keyword.
- This means that the <literal>DROP</literal> operation does
- not require the affected table to be copied (and so the table is
- not locked). You can also drop indexes offline (which causes the
+ This means that the <literal>DROP</literal> operation does not
+ require the affected table to be copied (and so the table is not
+ locked). You can also drop indexes offline (which causes the
table to be locked) using <literal>OFFLINE</literal>. The rules
and limitations governing online <literal>DROP ONLINE
INDEX</literal> and <literal>ADD OFFLINE INDEX</literal> are the
@@ -11573,8 +11573,8 @@
</para>
<para>
- When index hints are processed, they are collected in a
- single list by type (<literal>USE</literal>,
+ When index hints are processed, they are collected in a single
+ list by type (<literal>USE</literal>,
<literal>FORCE</literal>, <literal>IGNORE</literal>) and by
scope (<literal>FOR JOIN</literal>, <literal>FOR ORDER
BY</literal>, <literal>FOR GROUP BY</literal>). For example:
@@ -13466,8 +13466,8 @@
</para>
<para>
- The count of rows affected by <literal>TRUNCATE
- TABLE</literal> is accurate only when it is mapped to a
+ The count of rows affected by <literal>TRUNCATE TABLE</literal>
+ is accurate only when it is mapped to a
<literal>DELETE</literal> statement.
</para>
@@ -15155,14 +15155,13 @@
lock and released it. A request for a <literal>LOW_PRIORITY
WRITE</literal> lock, by contrast, allows subsequent
<literal>READ</literal> lock requests by other threads to be
- satisfied first if they occur while the
- <literal>LOW_PRIORITY WRITE</literal> request is waiting. You
- should use <literal>LOW_PRIORITY WRITE</literal> locks only if
- you are sure that eventually there will be a time when no
- threads have a <literal>READ</literal> lock. For
- <literal>InnoDB</literal> tables in transactional mode
- (autocommit = 0), a waiting <literal>LOW_PRIORITY
- WRITE</literal> lock acts like a regular
+ satisfied first if they occur while the <literal>LOW_PRIORITY
+ WRITE</literal> request is waiting. You should use
+ <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
+ that eventually there will be a time when no threads have a
+ <literal>READ</literal> lock. For <literal>InnoDB</literal>
+ tables in transactional mode (autocommit = 0), a waiting
+ <literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
<literal>READ</literal> lock requests to wait.)
</para>
@@ -18294,6 +18293,23 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ As of MySQL 5.1.25, if your table was created by a
+ different version of the MySQL server than the one you are
+ currently running, <literal>FOR UPGRADE</literal>
+ indicates that the table has an <filename>.frm</filename>
+ file with an incompatible version. In this case, the
+ result set returned by <literal>CHECK TABLE</literal>
+ contains a line with a <literal>Msg_type</literal> value
+ of <literal>error</literal> and a
+ <literal>Msg_text</literal> value of <literal>Table
+ upgrade required. Please do "REPAIR TABLE
+ `<replaceable>tbl_name</replaceable>`" to fix
+ it!</literal>
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
@@ -18909,19 +18925,35 @@
to see whether an upgrade is required and if it is necessary
performs the upgrade, following the same rules as
<literal>CHECK TABLE ... FOR UPGRADE</literal>. See
- <xref linkend="check-table"/>, for more information.
+ <xref linkend="check-table"/>, for more information. As of
+ MySQL 5.1.25, <literal>REPAIR TABLE</literal> without
+ <literal>USE_FRM</literal> upgrades the
+ <filename>.frm</filename> file to the current version.
</para>
<caution>
<para>
- Do not use <literal>USE_FRM</literal> if your table was
- created by a different version of the MySQL server than the
- one you are currently running. Doing so risks the loss of
- all rows in the table. It is particularly dangerous to use
- <literal>USE_FRM</literal> after the server returns this
- message:
+ As of MySQL 5.1.25, if you use <literal>USE_FRM</literal>
+ and your table was created by a different version of the
+ MySQL server than the one you are currently running,
+ <literal>REPAIR TABLE</literal> will not attempt to repair
+ the table. In this case, the result set returned by
+ <literal>REPAIR TABLE</literal> contains a line with a
+ <literal>Msg_type</literal> value of
+ <literal>error</literal> and a <literal>Msg_text</literal>
+ value of <literal>Failed repairing incompatible .FRM
+ file</literal>.
</para>
+ <para>
+ Prior to MySQL 5.1.25, <emphasis>do not use</emphasis>
+ <literal>USE_FRM</literal> if your table was created by a
+ different version of the MySQL server. Doing so risks the
+ loss of all rows in the table. It is particularly dangerous
+ to use <literal>USE_FRM</literal> after the server returns
+ this message:
+ </para>
+
<programlisting>
Table upgrade required. Please do
"REPAIR TABLE `<replaceable>tbl_name</replaceable>`" to fix it!
Modified: trunk/refman-6.0/sql-syntax.xml
===================================================================
--- trunk/refman-6.0/sql-syntax.xml 2008-05-20 15:58:31 UTC (rev 10788)
+++ trunk/refman-6.0/sql-syntax.xml 2008-05-20 16:57:24 UTC (rev 10789)
Changed blocks: 5, Lines Added: 26, Lines Deleted: 27; 4623 bytes
@@ -5559,15 +5559,15 @@
<para>
You can drop indexes online, using the <literal>ONLINE</literal>
- keyword. This means that the <literal>DROP</literal>
- operation does not require the affected table to be copied. You
- can also drop indexes offline, which does cause the table to be
- copied, using <literal>OFFLINE</literal>. The rules and
- limitations governing online <literal>DROP ONLINE
- INDEX</literal> and <literal>ADD OFFLINE INDEX</literal> are the
- same as for <literal>ALTER ONLINE TABLE ... DROP INDEX</literal>
- and <literal>ALTER OFFLINE TABLE ... DROP INDEX</literal>. For
- more information, see <xref linkend="alter-table"/>.
+ keyword. This means that the <literal>DROP</literal> operation
+ does not require the affected table to be copied. You can also
+ drop indexes offline, which does cause the table to be copied,
+ using <literal>OFFLINE</literal>. The rules and limitations
+ governing online <literal>DROP ONLINE INDEX</literal> and
+ <literal>ADD OFFLINE INDEX</literal> are the same as for
+ <literal>ALTER ONLINE TABLE ... DROP INDEX</literal> and
+ <literal>ALTER OFFLINE TABLE ... DROP INDEX</literal>. For more
+ information, see <xref linkend="alter-table"/>.
</para>
</section>
@@ -12015,8 +12015,8 @@
</para>
<para>
- When index hints are processed, they are collected in a
- single list by type (<literal>USE</literal>,
+ When index hints are processed, they are collected in a single
+ list by type (<literal>USE</literal>,
<literal>FORCE</literal>, <literal>IGNORE</literal>) and by
scope (<literal>FOR JOIN</literal>, <literal>FOR ORDER
BY</literal>, <literal>FOR GROUP BY</literal>). For example:
@@ -13907,8 +13907,8 @@
</para>
<para>
- The count of rows affected by <literal>TRUNCATE
- TABLE</literal> is accurate only when it is mapped to a
+ The count of rows affected by <literal>TRUNCATE TABLE</literal>
+ is accurate only when it is mapped to a
<literal>DELETE</literal> statement.
</para>
@@ -15613,14 +15613,13 @@
lock and released it. A request for a <literal>LOW_PRIORITY
WRITE</literal> lock, by contrast, allows subsequent
<literal>READ</literal> lock requests by other threads to be
- satisfied first if they occur while the
- <literal>LOW_PRIORITY WRITE</literal> request is waiting. You
- should use <literal>LOW_PRIORITY WRITE</literal> locks only if
- you are sure that eventually there will be a time when no
- threads have a <literal>READ</literal> lock. For
- <literal>InnoDB</literal> tables in transactional mode
- (autocommit = 0), a waiting <literal>LOW_PRIORITY
- WRITE</literal> lock acts like a regular
+ satisfied first if they occur while the <literal>LOW_PRIORITY
+ WRITE</literal> request is waiting. You should use
+ <literal>LOW_PRIORITY WRITE</literal> locks only if you are sure
+ that eventually there will be a time when no threads have a
+ <literal>READ</literal> lock. For <literal>InnoDB</literal>
+ tables in transactional mode (autocommit = 0), a waiting
+ <literal>LOW_PRIORITY WRITE</literal> lock acts like a regular
<literal>WRITE</literal> lock and causes subsequent
<literal>READ</literal> lock requests to wait.)
</para>
@@ -19286,12 +19285,12 @@
<caution>
<para>
- Do not use <literal>USE_FRM</literal> if your table was
- created by a different version of the MySQL server than the
- one you are currently running. Doing so risks the loss of
- all rows in the table. It is particularly dangerous to use
- <literal>USE_FRM</literal> after the server returns this
- message:
+ <emphasis>Do not use</emphasis> <literal>USE_FRM</literal>
+ if your table was created by a different version of the
+ MySQL server than the one you are currently running. Doing
+ so risks the loss of all rows in the table. It is
+ particularly dangerous to use <literal>USE_FRM</literal>
+ after the server returns this message:
</para>
<programlisting>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r10789 - in trunk: . dynamic-docs/changelog it/refman-5.1 pt/refman-5.1 refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 20 May |
