Author: paul
Date: 2008-06-24 18:41:23 +0200 (Tue, 24 Jun 2008)
New Revision: 11017
Log:
r32190@frost: paul | 2008-06-23 13:59:41 -0500
Wording tweaks
Modified:
trunk/refman-4.1/se-innodb-core.xml
trunk/refman-5.0/se-innodb-core.xml
trunk/refman-5.1/se-innodb-core.xml
trunk/refman-6.0/se-innodb-core.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:32186
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31778
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:32190
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:31778
Modified: trunk/refman-4.1/se-innodb-core.xml
===================================================================
--- trunk/refman-4.1/se-innodb-core.xml 2008-06-24 14:53:58 UTC (rev 11016)
+++ trunk/refman-4.1/se-innodb-core.xml 2008-06-24 16:41:23 UTC (rev 11017)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 16; 3174 bytes
@@ -1497,9 +1497,9 @@
The locks that <literal>InnoDB</literal> sets on index records
also affect the <quote>gap</quote> preceding that index
record. If a user has a shared or exclusive lock on record
- <literal>R</literal> in an index, another user cannot insert
- a new index record immediately before <literal>R</literal>
- in the order of the index.
+ <literal>R</literal> in an index, another user cannot insert a
+ new index record immediately before <literal>R</literal> in
+ the order of the index.
</para>
<para>
@@ -1508,10 +1508,11 @@
in searches or index scans. Next-key locking is still used to
ensure foreign key constraints and duplicate key checking.
Note that enabling this variable may cause phantom problems:
- Suppose that you want to read and lock all children from the
- <literal>child</literal> table with an identifier value larger
- than 100, with the intention of updating some column in the
- selected rows later:
+ Suppose that there is an index on the <literal>id</literal>
+ column and that you want to read and lock all children from
+ the <literal>child</literal> table with an identifier value
+ larger than 100, with the intention of updating some column in
+ the selected rows later:
</para>
<programlisting>
@@ -1519,15 +1520,14 @@
</programlisting>
<para>
- Suppose that there is an index on the <literal>id</literal>
- column. The query scans that index starting from the first
- record where <literal>id</literal> is larger than 100. If the
- locks set on the index records do not lock out inserts made in
- the gaps, another client can insert a new row into the table.
- If you execute the same <literal>SELECT</literal> within the
- same transaction, you see a new row in the result set returned
- by the query. This also means that if new items are added to
- the database, <literal>InnoDB</literal> does not guarantee
+ The query scans the index starting from the first record where
+ <literal>id</literal> is larger than 100. If the locks set on
+ the index records do not lock out inserts made in the gaps,
+ another client can insert a new row into the table. If you
+ execute the same <literal>SELECT</literal> within the same
+ transaction, you see a new row in the result set returned by
+ the query. This also means that if new items are added to the
+ database, <literal>InnoDB</literal> does not guarantee
serializability Therefore, if this variable is enabled
<literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>. (Conflict serializability
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-06-24 14:53:58 UTC (rev 11016)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-06-24 16:41:23 UTC (rev 11017)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 16; 3177 bytes
@@ -1480,9 +1480,9 @@
The locks that <literal>InnoDB</literal> sets on index records
also affect the <quote>gap</quote> preceding that index
record. If a user has a shared or exclusive lock on record
- <literal>R</literal> in an index, another user cannot insert
- a new index record immediately before <literal>R</literal>
- in the order of the index.
+ <literal>R</literal> in an index, another user cannot insert a
+ new index record immediately before <literal>R</literal> in
+ the order of the index.
</para>
<para>
@@ -1491,10 +1491,11 @@
in searches or index scans. Next-key locking is still used to
ensure foreign key constraints and duplicate key checking.
Note that enabling this variable may cause phantom problems:
- Suppose that you want to read and lock all children from the
- <literal>child</literal> table with an identifier value larger
- than 100, with the intention of updating some column in the
- selected rows later:
+ Suppose that there is an index on the <literal>id</literal>
+ column and that you want to read and lock all children from
+ the <literal>child</literal> table with an identifier value
+ larger than 100, with the intention of updating some column in
+ the selected rows later:
</para>
<programlisting>
@@ -1502,15 +1503,14 @@
</programlisting>
<para>
- Suppose that there is an index on the <literal>id</literal>
- column. The query scans that index starting from the first
- record where <literal>id</literal> is greater than 100. If the
- locks set on the index records do not lock out inserts made in
- the gaps, another client can insert a new row into the table.
- If you execute the same <literal>SELECT</literal> within the
- same transaction, you see a new row in the result set returned
- by the query. This also means that if new items are added to
- the database, <literal>InnoDB</literal> does not guarantee
+ The query scans the index starting from the first record where
+ <literal>id</literal> is greater than 100. If the locks set on
+ the index records do not lock out inserts made in the gaps,
+ another client can insert a new row into the table. If you
+ execute the same <literal>SELECT</literal> within the same
+ transaction, you see a new row in the result set returned by
+ the query. This also means that if new items are added to the
+ database, <literal>InnoDB</literal> does not guarantee
serializability. Therefore, if this variable is enabled
<literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>. (Conflict serializability
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-06-24 14:53:58 UTC (rev 11016)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-06-24 16:41:23 UTC (rev 11017)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 16; 3178 bytes
@@ -1521,9 +1521,9 @@
The locks that <literal>InnoDB</literal> sets on index records
also affect the <quote>gap</quote> preceding that index
record. If a user has a shared or exclusive lock on record
- <literal>R</literal> in an index, another user cannot insert
- a new index record immediately before <literal>R</literal>
- in the order of the index.
+ <literal>R</literal> in an index, another user cannot insert a
+ new index record immediately before <literal>R</literal> in
+ the order of the index.
</para>
<para>
@@ -1532,10 +1532,11 @@
in searches or index scans. Next-key locking is still used to
ensure foreign key constraints and duplicate key checking.
Note that enabling this variable may cause phantom problems:
- Suppose that you want to read and lock all children from the
- <literal>child</literal> table with an identifier value larger
- than 100, with the intention of updating some column in the
- selected rows later:
+ Suppose that there is an index on the <literal>id</literal>
+ column and that you want to read and lock all children from
+ the <literal>child</literal> table with an identifier value
+ larger than 100, with the intention of updating some column in
+ the selected rows later:
</para>
<programlisting>
@@ -1543,15 +1544,14 @@
</programlisting>
<para>
- Suppose that there is an index on the <literal>id</literal>
- column. The query scans that index starting from the first
- record where <literal>id</literal> is greater than 100. If the
- locks set on the index records do not lock out inserts made in
- the gaps, another client can insert a new row into the table.
- If you execute the same <literal>SELECT</literal> within the
- same transaction, you see a new row in the result set returned
- by the query. This also means that if new items are added to
- the database, <literal>InnoDB</literal> does not guarantee
+ The query scans the index starting from the first record where
+ <literal>id</literal> is greater than 100. If the locks set on
+ the index records do not lock out inserts made in the gaps,
+ another client can insert a new row into the table. If you
+ execute the same <literal>SELECT</literal> within the same
+ transaction, you see a new row in the result set returned by
+ the query. This also means that if new items are added to the
+ database, <literal>InnoDB</literal> does not guarantee
serializability. Therefore, if this variable is enabled,
<literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>. (Conflict serializability
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-06-24 14:53:58 UTC (rev 11016)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-06-24 16:41:23 UTC (rev 11017)
Changed blocks: 3, Lines Added: 16, Lines Deleted: 16; 3178 bytes
@@ -1454,9 +1454,9 @@
The locks that <literal>InnoDB</literal> sets on index records
also affect the <quote>gap</quote> preceding that index
record. If a user has a shared or exclusive lock on record
- <literal>R</literal> in an index, another user cannot insert
- a new index record immediately before <literal>R</literal>
- in the order of the index.
+ <literal>R</literal> in an index, another user cannot insert a
+ new index record immediately before <literal>R</literal> in
+ the order of the index.
</para>
<para>
@@ -1465,10 +1465,11 @@
in searches or index scans. Next-key locking is still used to
ensure foreign key constraints and duplicate key checking.
Note that enabling this variable may cause phantom problems:
- Suppose that you want to read and lock all children from the
- <literal>child</literal> table with an identifier value larger
- than 100, with the intention of updating some column in the
- selected rows later:
+ Suppose that there is an index on the <literal>id</literal>
+ column and that you want to read and lock all children from
+ the <literal>child</literal> table with an identifier value
+ larger than 100, with the intention of updating some column in
+ the selected rows later:
</para>
<programlisting>
@@ -1476,15 +1477,14 @@
</programlisting>
<para>
- Suppose that there is an index on the <literal>id</literal>
- column. The query scans that index starting from the first
- record where <literal>id</literal> is greater than 100. If the
- locks set on the index records do not lock out inserts made in
- the gaps, another client can insert a new row into the table.
- If you execute the same <literal>SELECT</literal> within the
- same transaction, you see a new row in the result set returned
- by the query. This also means that if new items are added to
- the database, <literal>InnoDB</literal> does not guarantee
+ The query scans the index starting from the first record where
+ <literal>id</literal> is greater than 100. If the locks set on
+ the index records do not lock out inserts made in the gaps,
+ another client can insert a new row into the table. If you
+ execute the same <literal>SELECT</literal> within the same
+ transaction, you see a new row in the result set returned by
+ the query. This also means that if new items are added to the
+ database, <literal>InnoDB</literal> does not guarantee
serializability. Therefore, if this variable is enabled,
<literal>InnoDB</literal> guarantees at most isolation level
<literal>READ COMMITTED</literal>. (Conflict serializability
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11017 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 24 Jun |
