Author: jstephens
Date: 2006-09-02 07:34:16 +0200 (Sat, 02 Sep 2006)
New Revision: 3204
Log:
Documenting Partitioning bugfixes:
Bug #15890, Bug #20548, Bug #21143,
Bug #21173, Bug #21357, Bug #21339,
Bug #21350, Bug #21658, Bug #21862
Modified:
trunk/refman-5.1/news-5.1.xml
trunk/refman-5.1/partitioning.xml
trunk/refman-5.1/sql-syntax.xml
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2006-09-02 03:16:22 UTC (rev 3203)
+++ trunk/refman-5.1/news-5.1.xml 2006-09-02 05:34:16 UTC (rev 3204)
Changed blocks: 3, Lines Added: 106, Lines Deleted: 2; 4676 bytes
@@ -628,6 +628,110 @@
REPAIR TABLE <replaceable>tbl_name</replaceable> QUICK;
</programlisting>
</listitem>
+
+ <listitem>
+ <para>
+ The server's handling of the number of partitions or
+ subpartitions specified in a <literal>PARTITIONS</literal>
+ or <literal>SUBPARTITIONS</literal> clause was changed.
+ Beginning with this release, the number of partitions must:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ be a positive, non-zero integer
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ not have any leading zeroes
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ not be an expression
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ Also beginning with this version, no attempt is made to
+ convert, truncate, or evaluate a <literal>PARTITIONS</literal>
+ or <literal>SUBPARTITIONS</literal> value; instead, the
+ <literal>CREATE TABLE</literal> or <literal>ALTER
+ TABLE</literal> statement containing the
+ <literal>PARTITIONS</literal> or
+ <literal>SUBPARTITIONS</literal> clause now fails with an
+ appropriate error message. (Bug #15890)
+ </para>
+
+ </listitem>
+
+ <listitem>
+ <para>
+ A misleading error message was displayed when attempting to
+ define a unique key that was not valid for a partitioned
+ table. (Bug #21862)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Errors could be generated during the execution of certain
+ prepared statements that ran queries on partitioned tables.
+ (Bug #21658)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Using relative paths for <literal>DATA DIRECTORY</literal> or
+ <literal>INDEX DIRECTORY</literal> with a partitioned table
+ generated a warning rather than an error, and caused
+ <quote>junk</quote> files to be created in the server's data
+ directory. (Bug #21350)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Using <literal>EXPLAIN PARTITIONS</literal> with a query on a
+ table whose partitioning expression was based on the value of
+ a <literal>DATE</literal> column could sometimes cause the
+ server to crash. (Bug #21339)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Running <literal>SHOW TABLE STATUS</literal> on any
+ <literal>InnoDB</literal> table having at least one record
+ could crash the server. Note that this was not due to any
+ issue in the <literal>InnoDB</literal> storage engine, but
+ rather with <literal>AUTO_INCREMENT</literal> handling in the
+ partitioning code — however, the table did not have to
+ have an <literal>AUTO_INCREMENT</literal> column for the bug
+ to manifest. (Bug #21173)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Some <literal>ALTER TABLE</literal> statements affecting a
+ table's subpartitioning could hang. (Bug #21143)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Scheduled events that invoked stored procedures executing DDL
+ operations on partitioned tables could crash the server. (Bug
+ #20548)
+ </para>
+ </listitem>
<listitem>
<para>
@@ -651,7 +755,7 @@
<listitem>
<para>
The server used <literal>#sql</literal> as a prefix for hidden
- table names, but it is also possible for users to use that as
+ table names, but it was also possible for users to use that as
a table name prefix, which caused some operations to fail. Now
the server uses <literal>#.sql</literal> as the prefix. (Bug
#1405)
@@ -1626,7 +1730,7 @@
subpartitions, could sometimes crash the server. These issues
were associated with a failure reported in the
<literal>partition_range</literal> test. (Bug #20766, Bug
- #20767, Bug #20893)
+ #20767, Bug #20893, Bug #21357)
</para>
</listitem>
Modified: trunk/refman-5.1/partitioning.xml
===================================================================
--- trunk/refman-5.1/partitioning.xml 2006-09-02 03:16:22 UTC (rev 3203)
+++ trunk/refman-5.1/partitioning.xml 2006-09-02 05:34:16 UTC (rev 3204)
Changed blocks: 1, Lines Added: 10, Lines Deleted: 0; 904 bytes
@@ -666,6 +666,16 @@
partition names <literal>mypart</literal> and
<literal>MyPart</literal>.
</para>
+
+ <para>
+ When you specify the number of partitions for the table, this must
+ be expressed as a positive, non-zero integer literal with no
+ leading zeroes, and may not be an expression such as
+ <literal>0.8E+01</literal> or <literal>6-2</literal>, even if it
+ evaluates as an integer. (Beginning with MySQL 5.1.12, decimal
+ fractions are no longer truncated, but instead are disallowed
+ entirely.)
+ </para>
<para>
In the sections that follow, we do not necessarily provide all
Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml 2006-09-02 03:16:22 UTC (rev 3203)
+++ trunk/refman-5.1/sql-syntax.xml 2006-09-02 05:34:16 UTC (rev 3204)
Changed blocks: 2, Lines Added: 38, Lines Deleted: 1; 2079 bytes
@@ -895,7 +895,10 @@
primary key) that the table might have, and the column or
columns used in the partitioning expression, as discussed in
<link linkend="partitioning-limitations-partitioning-keys-unique-keys">Partitioning
- Limitations: Partitioning Keys and Unique Keys</link>.
+ Limitations: Partitioning Keys and Unique Keys</link>. The
+ <literal>CREATE TABLE ... PARTITION BY</literal> rules for specifying the
+ number of partitions also apply to <literal>ALTER
+ TABLE ... PARTITION BY</literal>.
</para>
<para>
@@ -3529,6 +3532,40 @@
integer value.
</para>
</listitem>
+
+ <listitem>
+ <para>
+ MySQL 5.1.12 introduces rigourous checking of the value used
+ in a <literal>PARTITIONS</literal> or
+ <literal>SUBPARTITIONS</literal> clause. Beginning with this
+ version, this value must adhere to the following rules:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ The value must be a positive, non-zero integer.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ No leading zeroes are permitted.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The value must be an integer literal, and cannot not be an
+ expression. For example, <literal>PARTITIONS
+ 0.2E+01</literal> is not allowed, even though
+ <literal>0.2E+01</literal> evaluates to
+ <literal>2</literal>. (Bug #15890)
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </listitem>
</itemizedlist>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r3204 - trunk/refman-5.1 | jon | 2 Sep |
