Author: paul
Date: 2008-06-21 19:22:27 +0200 (Sat, 21 Jun 2008)
New Revision: 11000
Log:
r32158@frost: paul | 2008-06-21 12:19:13 -0500
Fix documentation bug:
Bug #36286 innodb_lock_wait_timeout documentation unclear
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:32157
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:32158
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-21 17:22:21 UTC (rev 10999)
+++ trunk/refman-4.1/se-innodb-core.xml 2008-06-21 17:22:27 UTC (rev 11000)
Changed blocks: 2, Lines Added: 25, Lines Deleted: 11; 2821 bytes
@@ -1447,14 +1447,21 @@
<para>
The timeout in seconds an <literal>InnoDB</literal>
- transaction may wait for a lock before being rolled back.
- <literal>InnoDB</literal> automatically detects transaction
- deadlocks in its own lock table and rolls back the
- transaction. The default is 50 seconds. A lock wait for a
- MySQL table lock does not happen inside
+ transaction may wait for a lock before being rolled back. The
+ default is 50 seconds.
+ </para>
+
+ <para>
+ A lock wait for a MySQL table lock does not happen inside
<literal>InnoDB</literal>, and this timeout does not apply to
- that wait.
+ waits for table locks.
</para>
+
+ <para>
+ <literal>InnoDB</literal> does detect transaction deadlocks in
+ its own lock table immediately and rolls back one transaction.
+ This timeout does not apply to such a wait.
+ </para>
</listitem>
<listitem>
@@ -1483,15 +1490,22 @@
<literal>InnoDB</literal> performs row-level locking in such a
way that when it searches or scans a table index, it sets
shared or exclusive locks on any index records it encounters.
- Thus, the row-level locks are actually index record locks. The
- locks that <literal>InnoDB</literal> sets on index records
+ Thus, the row-level locks are actually index record locks.
+ </para>
+
+ <para>
+ 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
<emphasis>R</emphasis> in an index, another user cannot insert
a new index record immediately before <emphasis>R</emphasis>
- in the order of the index. Enabling this variable causes
- <literal>InnoDB</literal> not to use next-key locking in
- searches or index scans. Next-key locking is still used to
+ in the order of the index.
+ </para>
+
+ <para>
+ Enabling <literal>innodb_locks_unsafe_for_binlog</literal>
+ causes <literal>InnoDB</literal> not to use next-key locking
+ 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
Modified: trunk/refman-5.0/se-innodb-core.xml
===================================================================
--- trunk/refman-5.0/se-innodb-core.xml 2008-06-21 17:22:21 UTC (rev 10999)
+++ trunk/refman-5.0/se-innodb-core.xml 2008-06-21 17:22:27 UTC (rev 11000)
Changed blocks: 3, Lines Added: 48, Lines Deleted: 15; 4453 bytes
@@ -1411,14 +1411,40 @@
<para>
The timeout in seconds an <literal>InnoDB</literal>
- transaction may wait for a lock before being rolled back.
- <literal>InnoDB</literal> automatically detects transaction
- deadlocks in its own lock table and rolls back the
- transaction. The default is 50 seconds. A lock wait for a
- MySQL table lock does not happen inside
- <literal>InnoDB</literal>, and this timeout does not apply to
- that wait.
+ transaction may wait for a row lock before giving up. The
+ default is 50 seconds. When trying to access a row that is
+ locked by another <literal>InnoDB</literal> transaction a
+ connection will hang for at most this many seconds before
+ issuing the following error:
</para>
+
+<programlisting>
+ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
+</programlisting>
+
+ <para>
+ In this case, the current statement is not executed. The
+ current transaction is <emphasis>not</emphasis> rolled back.
+ (Until MySQL 5.0.13 <literal>InnoDB</literal> rolled back the
+ entire transaction if a lock wait timeout happened. You can
+ restore this behavior by starting the server with the
+ <option>--innodb_rollback_on_timeout</option> option,
+ available as of MySQL 5.0.32. See also
+ <xref linkend="innodb-error-handling"/>.)
+ </para>
+
+ <para>
+ <literal>innodb_lock_wait_timeout</literal> applies to
+ <literal>InnoDB</literal> row locks only. A MySQL table lock
+ does not happen inside <literal>InnoDB</literal> and this
+ timeout does not apply to waits for table locks.
+ </para>
+
+ <para>
+ <literal>InnoDB</literal> does detect transaction deadlocks in
+ its own lock table immediately and rolls back one transaction.
+ This timeout does not apply to such a wait.
+ </para>
</listitem>
<listitem>
@@ -1447,15 +1473,22 @@
<literal>InnoDB</literal> performs row-level locking in such a
way that when it searches or scans a table index, it sets
shared or exclusive locks on any index records it encounters.
- Thus, the row-level locks are actually index record locks. The
- locks that <literal>InnoDB</literal> sets on index records
+ Thus, the row-level locks are actually index record locks.
+ </para>
+
+ <para>
+ 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
- <emphasis>R</emphasis> in an index, another user cannot insert
- a new index record immediately before <emphasis>R</emphasis>
- in the order of the index. Enabling this variable causes
- <literal>InnoDB</literal> not to use next-key locking in
- searches or index scans. Next-key locking is still used to
+ <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>
+ Enabling <literal>innodb_locks_unsafe_for_binlog</literal>
+ causes <literal>InnoDB</literal> not to use next-key locking
+ 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
@@ -6301,7 +6334,7 @@
if a lock wait timeout happened. You can restore this behavior
by starting the server with the
<option>--innodb_rollback_on_timeout</option> option,
- available as of MySQL 5.0.32). You should normally retry the
+ available as of MySQL 5.0.32.) You should normally retry the
statement if using the current behavior or the entire
transaction if using the old behavior.
</para>
Modified: trunk/refman-5.1/se-innodb-core.xml
===================================================================
--- trunk/refman-5.1/se-innodb-core.xml 2008-06-21 17:22:21 UTC (rev 10999)
+++ trunk/refman-5.1/se-innodb-core.xml 2008-06-21 17:22:27 UTC (rev 11000)
Changed blocks: 2, Lines Added: 43, Lines Deleted: 12; 3715 bytes
@@ -1454,14 +1454,38 @@
<para>
The timeout in seconds an <literal>InnoDB</literal>
- transaction may wait for a lock before being rolled back.
- <literal>InnoDB</literal> automatically detects transaction
- deadlocks in its own lock table and rolls back the
- transaction. The default is 50 seconds. A lock wait for a
- MySQL table lock does not happen inside
- <literal>InnoDB</literal>, and this timeout does not apply to
- that wait.
+ transaction may wait for a row lock before giving up. The
+ default is 50 seconds. When trying to access a row that is
+ locked by another <literal>InnoDB</literal> transaction a
+ connection will hang for at most this many seconds before
+ issuing the following error:
</para>
+
+<programlisting>
+ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
+</programlisting>
+
+ <para>
+ In this case, the current statement is not executed. The
+ current transaction is <emphasis>not</emphasis> rolled back.
+ (To have the entire transaction roll back, start the server
+ with the <option>--innodb_rollback_on_timeout</option> option,
+ available as of MySQL 5.1.15. See also
+ <xref linkend="innodb-error-handling"/>.)
+ </para>
+
+ <para>
+ <literal>innodb_lock_wait_timeout</literal> applies to
+ <literal>InnoDB</literal> row locks only. A MySQL table lock
+ does not happen inside <literal>InnoDB</literal> and this
+ timeout does not apply to waits for table locks.
+ </para>
+
+ <para>
+ <literal>InnoDB</literal> does detect transaction deadlocks in
+ its own lock table immediately and rolls back one transaction.
+ This timeout does not apply to such a wait.
+ </para>
</listitem>
<listitem>
@@ -1490,15 +1514,22 @@
<literal>InnoDB</literal> performs row-level locking in such a
way that when it searches or scans a table index, it sets
shared or exclusive locks on any index records it encounters.
- Thus, the row-level locks are actually index record locks. The
- locks that <literal>InnoDB</literal> sets on index records
+ Thus, the row-level locks are actually index record locks.
+ </para>
+
+ <para>
+ 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
<emphasis>R</emphasis> in an index, another user cannot insert
a new index record immediately before <emphasis>R</emphasis>
- in the order of the index. Enabling this variable causes
- <literal>InnoDB</literal> not to use next-key locking in
- searches or index scans. Next-key locking is still used to
+ in the order of the index.
+ </para>
+
+ <para>
+ Enabling <literal>innodb_locks_unsafe_for_binlog</literal>
+ causes <literal>InnoDB</literal> not to use next-key locking
+ 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
Modified: trunk/refman-6.0/se-innodb-core.xml
===================================================================
--- trunk/refman-6.0/se-innodb-core.xml 2008-06-21 17:22:21 UTC (rev 10999)
+++ trunk/refman-6.0/se-innodb-core.xml 2008-06-21 17:22:27 UTC (rev 11000)
Changed blocks: 2, Lines Added: 42, Lines Deleted: 12; 3675 bytes
@@ -1388,14 +1388,37 @@
<para>
The timeout in seconds an <literal>InnoDB</literal>
- transaction may wait for a lock before being rolled back.
- <literal>InnoDB</literal> automatically detects transaction
- deadlocks in its own lock table and rolls back the
- transaction. The default is 50 seconds. A lock wait for a
- MySQL table lock does not happen inside
- <literal>InnoDB</literal>, and this timeout does not apply to
- that wait.
+ transaction may wait for a row lock before giving up. The
+ default is 50 seconds. When trying to access a row that is
+ locked by another <literal>InnoDB</literal> transaction a
+ connection will hang for at most this many seconds before
+ issuing the following error:
</para>
+
+<programlisting>
+ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
+</programlisting>
+
+ <para>
+ In this case, the current statement is not executed. The
+ current transaction is <emphasis>not</emphasis> rolled back.
+ (To have the entire transaction roll back, start the server
+ with the <option>--innodb_rollback_on_timeout</option> option.
+ See also <xref linkend="innodb-error-handling"/>.)
+ </para>
+
+ <para>
+ <literal>innodb_lock_wait_timeout</literal> applies to
+ <literal>InnoDB</literal> row locks only. A MySQL table lock
+ does not happen inside <literal>InnoDB</literal> and this
+ timeout does not apply to waits for table locks.
+ </para>
+
+ <para>
+ <literal>InnoDB</literal> does detect transaction deadlocks in
+ its own lock table immediately and rolls back one transaction.
+ This timeout does not apply to such a wait.
+ </para>
</listitem>
<listitem>
@@ -1424,15 +1447,22 @@
<literal>InnoDB</literal> performs row-level locking in such a
way that when it searches or scans a table index, it sets
shared or exclusive locks on any index records it encounters.
- Thus, the row-level locks are actually index record locks. The
- locks that <literal>InnoDB</literal> sets on index records
+ Thus, the row-level locks are actually index record locks.
+ </para>
+
+ <para>
+ 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
<emphasis>R</emphasis> in an index, another user cannot insert
a new index record immediately before <emphasis>R</emphasis>
- in the order of the index. Enabling this variable causes
- <literal>InnoDB</literal> not to use next-key locking in
- searches or index scans. Next-key locking is still used to
+ in the order of the index.
+ </para>
+
+ <para>
+ Enabling <literal>innodb_locks_unsafe_for_binlog</literal>
+ causes <literal>InnoDB</literal> not to use next-key locking
+ 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
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11000 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0 | paul | 21 Jun |
