From: john.russell
Date: April 7 2011 6:51pm
Subject: svn commit - mysqldoc@oter02: r25784 - trunk/refman-5.6
List-Archive: http://lists.mysql.com/commits/134978
Message-Id: <20110407185110.5B8EA78064@oter02.norway.sun.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Author: jdrussel
Date: 2011-04-07 20:51:10 +0200 (Thu, 07 Apr 2011)
New Revision: 25784

Log:
Add detail for innodb_print_all_deadlocks option.
Will need to mention that option in a few other places
that talk about deadlocks or InnoDB troubleshooting.


Modified:
   trunk/refman-5.6/se-innodb-core.xml


Modified: trunk/refman-5.6/se-innodb-core.xml
===================================================================
--- trunk/refman-5.6/se-innodb-core.xml	2011-04-07 18:49:37 UTC (rev 25783)
+++ trunk/refman-5.6/se-innodb-core.xml	2011-04-07 18:51:10 UTC (rev 25784)
Changed blocks: 1, Lines Added: 20, Lines Deleted: 1; 1686 bytes

@@ -11682,7 +11682,26 @@
 
           <para condition="dynamic:optvar:item" role="5.6:mysqld:innodb_print_all_deadlocks"/>
 
-          <para></para>
+          <para>
+            When this option is enabled, information about all
+            <link linkend="glos_deadlock">deadlocks</link> in
+            <literal>InnoDB</literal> user transactions is recorded in
+            the <literal>mysqld</literal> error log. Otherwise, you see
+            information about only the last deadlock, using the
+            <literal role="stmt">SHOW ENGINE INNODB STATUS</literal>
+            command. An occasional <literal>InnoDB</literal> deadlock is
+            not necessarily an issue, because <literal>InnoDB</literal>
+            detects the condition immediately, and rolls back one of the
+            transactions automatically. You might use this option to
+            troubleshoot why deadlocks are happening if an application
+            does not have appropriate error-handling logic to detect the
+            rollback and retry its operation. A large number of
+            deadlocks might indicate the need to restructure
+            transactions that issue <literal>SELECT ... FOR
+            UPDATE</literal> statements for multiple tables, so that
+            each transaction accesses the tables in the same order, thus
+            avoiding the deadlock condition.
+          </para>
         </listitem>
 
         <listitem>