Author: mcbrown
Date: 2007-02-12 17:24:57 +0100 (Mon, 12 Feb 2007)
New Revision: 4900
Log:
Extending the update notes on the MERG engine changes (WL#3567)
Adding entries to release notes for change of behaviour
Change of behaviour note for MBR
Modified:
trunk/refman-4.1/news-4.1.xml
trunk/refman-4.1/storage-engines.xml
trunk/refman-5.0/functions.xml
trunk/refman-5.0/releasenotes-es-5.0.xml
trunk/refman-5.0/se-merge.xml
trunk/refman-5.1/news-5.1.xml
trunk/refman-5.1/se-merge.xml
Modified: trunk/refman-4.1/news-4.1.xml
===================================================================
--- trunk/refman-4.1/news-4.1.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-4.1/news-4.1.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 1, Lines Added: 14, Lines Deleted: 0; 1106 bytes
@@ -208,6 +208,20 @@
<listitem>
<para>
+ <emphasis role="bold">Important</emphasis>: When using
+ <literal>MERGE</literal> tables the definition of the
+ <literal>MERGE</literal> table and the
+ <literal>MyISAM</literal> tables are checked each time the
+ tables are opened for access (including any
+ <literal>SELECT</literal> or <literal>INSERT</literal>
+ statement. Each table is compared for column order, types,
+ sizes and associated. If there is a difference in any one of
+ the tables then the statement will fail.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The <option>--memlock</option> option relies on system calls
that are unreliable on some operating systems. If a crash
occurs, the server now checks whether
Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-4.1/storage-engines.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 1, Lines Added: 63, Lines Deleted: 27; 5388 bytes
@@ -2209,40 +2209,76 @@
<listitem>
<para>
- When you create or alter <literal>MERGE</literal> table,
- there is no check to ensure that the underlying tables are
- existing <literal>MyISAM</literal> tables and have identical
- structures. When the <literal>MERGE</literal> table is used,
- MySQL checks that the row length for all mapped tables is
- equal, but this is not foolproof. If you create a
- <literal>MERGE</literal> table from dissimilar
- <literal>MyISAM</literal> tables, you are very likely to run
- into strange problems.
+ In MySQL 4.1.23 and later, the definition of the
+ <literal>MyISAM</literal> tables and the
+ <literal>MERGE</literal> table are checked when the tables
+ are accessed (for example, as part of a
+ <literal>SELECT</literal> or <literal>INSERT</literal>
+ statement). The checks ensure that the definitions of the
+ tables and the parent <literal>MERGE</literal> table
+ definition match by comparing column order, types, sizes and
+ associated indexes. If there is a difference between the
+ tables then an error will be returned and the statement will
+ fail.
</para>
<para>
- Similarly, if you create a <literal>MERGE</literal> table
- from non-<literal>MyISAM</literal> tables, or if you drop an
- underlying table or alter it to be a
- non-<literal>MyISAM</literal> table, no error for the
- <literal>MERGE</literal> table occurs until later when you
- attempt to use it.
+ Because these checks take place when the tables are opened,
+ any changes to the definition of a single, including column
+ changes, ocolumn ordering and engine alterations will cause
+ the statement to fail.
</para>
<para>
- Because the underlying <literal>MyISAM</literal> tables need
- not exist when the <literal>MERGE</literal> table is
- created, you can create the tables in any order, as long as
- you do not use the <literal>MERGE</literal> table until all
- of its underlying tables are in place. Also, if you can
- ensure that a <literal>MERGE</literal> table will not be
- used during a given period, you can perform maintenance
- operations on the underlying tables, such as backing up or
- restoring them, altering them, or dropping and recreating
- them. It is not necessary to redefine the
- <literal>MERGE</literal> table temporarily to exclude the
- underlying tables while you are operating on them.
+ For MySQL 4.1.22 and earlier:
</para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When you create or alter <literal>MERGE</literal> table,
+ there is no check to ensure that the underlying tables
+ are existing <literal>MyISAM</literal> tables and have
+ identical structures. When the <literal>MERGE</literal>
+ table is used, MySQL checks that the row length for all
+ mapped tables is equal, but this is not foolproof. If
+ you create a <literal>MERGE</literal> table from
+ dissimilar <literal>MyISAM</literal> tables, you are
+ very likely to run into strange problems.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Similarly, if you create a <literal>MERGE</literal>
+ table from non-<literal>MyISAM</literal> tables, or if
+ you drop an underlying table or alter it to be a
+ non-<literal>MyISAM</literal> table, no error for the
+ <literal>MERGE</literal> table occurs until later when
+ you attempt to use it.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Because the underlying <literal>MyISAM</literal> tables
+ need not exist when the <literal>MERGE</literal> table
+ is created, you can create the tables in any order, as
+ long as you do not use the <literal>MERGE</literal>
+ table until all of its underlying tables are in place.
+ Also, if you can ensure that a <literal>MERGE</literal>
+ table will not be used during a given period, you can
+ perform maintenance operations on the underlying tables,
+ such as backing up or restoring them, altering them, or
+ dropping and recreating them. It is not necessary to
+ redefine the <literal>MERGE</literal> table temporarily
+ to exclude the underlying tables while you are operating
+ on them.
+ </para>
+ </listitem>
+
+ </itemizedlist>
</listitem>
<listitem>
Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-5.0/functions.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 719 bytes
@@ -13509,7 +13509,7 @@
generated value that was set for an
<literal>AUTO_INCREMENT</literal> column by the
<emphasis>most recently executed</emphasis>
- <literal>INSERT</literal> or <literal>UPDATE</literal>
+ <literal>INSERT</literal>
statement to affect such a column. For example, after
inserting a row that generates an
<literal>AUTO_INCREMENT</literal> value, you can get the
Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 1, Lines Added: 13, Lines Deleted: 0; 980 bytes
@@ -99,6 +99,19 @@
</para>
</listitem>
+ <listitem>
+ <para>
+ <emphasis role="bold">Important</emphasis>: When using <literal>MERGE</literal> tables the definition of
+ the <literal>MERGE</literal> table and the
+ <literal>MyISAM</literal> tables are checked each time the
+ tables are opened for access (including any
+ <literal>SELECT</literal> or <literal>INSERT</literal>
+ statement. Each table is compared for column order, types,
+ sizes and associated. If there is a difference in any one of
+ the tables then the statement will fail.
+ </para>
+ </listitem>
+
</itemizedlist>
<para>
Modified: trunk/refman-5.0/se-merge.xml
===================================================================
--- trunk/refman-5.0/se-merge.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-5.0/se-merge.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 1, Lines Added: 61, Lines Deleted: 27; 5152 bytes
@@ -576,40 +576,74 @@
<listitem>
<para>
- When you create or alter <literal>MERGE</literal> table, there
- is no check to ensure that the underlying tables are existing
- <literal>MyISAM</literal> tables and have identical
- structures. When the <literal>MERGE</literal> table is used,
- MySQL checks that the row length for all mapped tables is
- equal, but this is not foolproof. If you create a
- <literal>MERGE</literal> table from dissimilar
- <literal>MyISAM</literal> tables, you are very likely to run
- into strange problems.
+ In MySQL 5.0.36 and later, the definition of the
+ <literal>MyISAM</literal> tables and the
+ <literal>MERGE</literal> table are checked when the tables are
+ accessed (for example, as part of a <literal>SELECT</literal>
+ or <literal>INSERT</literal> statement). The checks ensure
+ that the definitions of the tables and the parent
+ <literal>MERGE</literal> table definition match by comparing
+ column order, types, sizes and associated indexes. If there is
+ a difference between the tables then an error will be returned
+ and the statement will fail.
</para>
<para>
- Similarly, if you create a <literal>MERGE</literal> table from
- non-<literal>MyISAM</literal> tables, or if you drop an
- underlying table or alter it to be a
- non-<literal>MyISAM</literal> table, no error for the
- <literal>MERGE</literal> table occurs until later when you
- attempt to use it.
+ Because these checks take place when the tables are opened,
+ any changes to the definition of a single, including column
+ changes, ocolumn ordering and engine alterations will cause
+ the statement to fail.
</para>
<para>
- Because the underlying <literal>MyISAM</literal> tables need
- not exist when the <literal>MERGE</literal> table is created,
- you can create the tables in any order, as long as you do not
- use the <literal>MERGE</literal> table until all of its
- underlying tables are in place. Also, if you can ensure that a
- <literal>MERGE</literal> table will not be used during a given
- period, you can perform maintenance operations on the
- underlying tables, such as backing up or restoring them,
- altering them, or dropping and recreating them. It is not
- necessary to redefine the <literal>MERGE</literal> table
- temporarily to exclude the underlying tables while you are
- operating on them.
+ In MySQL 5.0.35 and earlier:
</para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When you create or alter <literal>MERGE</literal> table,
+ there is no check to ensure that the underlying tables are
+ existing <literal>MyISAM</literal> tables and have
+ identical structures. When the <literal>MERGE</literal>
+ table is used, MySQL checks that the row length for all
+ mapped tables is equal, but this is not foolproof. If you
+ create a <literal>MERGE</literal> table from dissimilar
+ <literal>MyISAM</literal> tables, you are very likely to
+ run into strange problems.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Similarly, if you create a <literal>MERGE</literal> table
+ from non-<literal>MyISAM</literal> tables, or if you drop
+ an underlying table or alter it to be a
+ non-<literal>MyISAM</literal> table, no error for the
+ <literal>MERGE</literal> table occurs until later when you
+ attempt to use it.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Because the underlying <literal>MyISAM</literal> tables
+ need not exist when the <literal>MERGE</literal> table is
+ created, you can create the tables in any order, as long
+ as you do not use the <literal>MERGE</literal> table until
+ all of its underlying tables are in place. Also, if you
+ can ensure that a <literal>MERGE</literal> table will not
+ be used during a given period, you can perform maintenance
+ operations on the underlying tables, such as backing up or
+ restoring them, altering them, or dropping and recreating
+ them. It is not necessary to redefine the
+ <literal>MERGE</literal> table temporarily to exclude the
+ underlying tables while you are operating on them.
+ </para>
+ </listitem>
+
+ </itemizedlist>
</listitem>
<listitem>
Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-5.1/news-5.1.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 2, Lines Added: 22, Lines Deleted: 0; 1648 bytes
@@ -609,6 +609,20 @@
<listitem>
<para>
+ <emphasis role="bold">Important</emphasis>: When using
+ <literal>MERGE</literal> tables the definition of the
+ <literal>MERGE</literal> table and the
+ <literal>MyISAM</literal> tables are checked each time the
+ tables are opened for access (including any
+ <literal>SELECT</literal> or <literal>INSERT</literal>
+ statement. Each table is compared for column order, types,
+ sizes and associated. If there is a difference in any one of
+ the tables then the statement will fail.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Remote servers for use with the <literal>FEDERATED</literal>
storage engine now can be managed with the new
<literal>CREATE/ALTER/DROP SERVER</literal> syntax.
@@ -3995,6 +4009,14 @@
<listitem>
<para>
+ The default binary log format (as used during replication) is
+ now Mixed based, automatically using a combination of
+ row-based and statement based log events as appropriate.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
The general query log and slow query logs now can be enabled
or disabled at runtime with the <literal>general_log</literal>
and <literal>slow_query_log</literal> system variables, and
Modified: trunk/refman-5.1/se-merge.xml
===================================================================
--- trunk/refman-5.1/se-merge.xml 2007-02-12 15:39:41 UTC (rev 4899)
+++ trunk/refman-5.1/se-merge.xml 2007-02-12 16:24:57 UTC (rev 4900)
Changed blocks: 2, Lines Added: 77, Lines Deleted: 42; 6935 bytes
@@ -78,21 +78,22 @@
<literal>MERGE</literal> table.
</para>
- <para>
- <emphasis role="bold">Note</emphasis>: The use of
- <literal>MERGE</literal> tables entails the following security
- issue: If a user has access to <literal>MyISAM</literal> table
- <replaceable>t</replaceable>, that user can create a
- <literal>MERGE</literal> table <replaceable>m</replaceable> that
- accesses <replaceable>t</replaceable>. However, if the user's
- privileges on <replaceable>t</replaceable> are subsequently revoked,
- the user can continue to access <replaceable>t</replaceable> by
- doing so through <replaceable>m</replaceable>. If this behavior is
- undesirable, you can start the server with the new
- <option>--skip-merge</option> option to disable the
- <literal>MERGE</literal> storage engine. This option is available as
- of MySQL 5.1.12.
- </para>
+ <note>
+ <para>
+ The use of <literal>MERGE</literal> tables entails the following
+ security issue: If a user has access to <literal>MyISAM</literal>
+ table <replaceable>t</replaceable>, that user can create a
+ <literal>MERGE</literal> table <replaceable>m</replaceable> that
+ accesses <replaceable>t</replaceable>. However, if the user's
+ privileges on <replaceable>t</replaceable> are subsequently
+ revoked, the user can continue to access
+ <replaceable>t</replaceable> by doing so through
+ <replaceable>m</replaceable>. If this behavior is undesirable, you
+ can start the server with the new <option>--skip-merge</option>
+ option to disable the <literal>MERGE</literal> storage engine.
+ This option is available as of MySQL 5.1.12.
+ </para>
+ </note>
<para>
If you <literal>DROP</literal> the <literal>MERGE</literal> table,
@@ -567,40 +568,74 @@
<listitem>
<para>
- When you create or alter <literal>MERGE</literal> table, there
- is no check to ensure that the underlying tables are existing
- <literal>MyISAM</literal> tables and have identical
- structures. When the <literal>MERGE</literal> table is used,
- MySQL checks that the row length for all mapped tables is
- equal, but this is not foolproof. If you create a
- <literal>MERGE</literal> table from dissimilar
- <literal>MyISAM</literal> tables, you are very likely to run
- into strange problems.
+ In MySQL 5.1.15 and later, the definition of the
+ <literal>MyISAM</literal> tables and the
+ <literal>MERGE</literal> table are checked when the tables are
+ accessed (for example, as part of a <literal>SELECT</literal>
+ or <literal>INSERT</literal> statement). The checks ensure
+ that the definitions of the tables and the parent
+ <literal>MERGE</literal> table definition match by comparing
+ column order, types, sizes and associated indexes. If there is
+ a difference between the tables then an error will be returned
+ and the statement will fail.
</para>
<para>
- Similarly, if you create a <literal>MERGE</literal> table from
- non-<literal>MyISAM</literal> tables, or if you drop an
- underlying table or alter it to be a
- non-<literal>MyISAM</literal> table, no error for the
- <literal>MERGE</literal> table occurs until later when you
- attempt to use it.
+ Because these checks take place when the tables are opened,
+ any changes to the definition of a single, including column
+ changes, ocolumn ordering and engine alterations will cause
+ the statement to fail.
</para>
<para>
- Because the underlying <literal>MyISAM</literal> tables need
- not exist when the <literal>MERGE</literal> table is created,
- you can create the tables in any order, as long as you do not
- use the <literal>MERGE</literal> table until all of its
- underlying tables are in place. Also, if you can ensure that a
- <literal>MERGE</literal> table will not be used during a given
- period, you can perform maintenance operations on the
- underlying tables, such as backing up or restoring them,
- altering them, or dropping and recreating them. It is not
- necessary to redefine the <literal>MERGE</literal> table
- temporarily to exclude the underlying tables while you are
- operating on them.
+ In MySQL 5.1.14 and earlier:
</para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ When you create or alter <literal>MERGE</literal> table,
+ there is no check to ensure that the underlying tables are
+ existing <literal>MyISAM</literal> tables and have
+ identical structures. When the <literal>MERGE</literal>
+ table is used, MySQL checks that the row length for all
+ mapped tables is equal, but this is not foolproof. If you
+ create a <literal>MERGE</literal> table from dissimilar
+ <literal>MyISAM</literal> tables, you are very likely to
+ run into strange problems.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Similarly, if you create a <literal>MERGE</literal> table
+ from non-<literal>MyISAM</literal> tables, or if you drop
+ an underlying table or alter it to be a
+ non-<literal>MyISAM</literal> table, no error for the
+ <literal>MERGE</literal> table occurs until later when you
+ attempt to use it.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Because the underlying <literal>MyISAM</literal> tables
+ need not exist when the <literal>MERGE</literal> table is
+ created, you can create the tables in any order, as long
+ as you do not use the <literal>MERGE</literal> table until
+ all of its underlying tables are in place. Also, if you
+ can ensure that a <literal>MERGE</literal> table will not
+ be used during a given period, you can perform maintenance
+ operations on the underlying tables, such as backing up or
+ restoring them, altering them, or dropping and recreating
+ them. It is not necessary to redefine the
+ <literal>MERGE</literal> table temporarily to exclude the
+ underlying tables while you are operating on them.
+ </para>
+ </listitem>
+
+ </itemizedlist>
</listitem>
<listitem>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r4900 - in trunk: refman-4.1 refman-5.0 refman-5.1 | mcbrown | 12 Feb |
