Comments on: A little-known way to cause a database deadlock http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/ Stay curious! Thu, 24 Jul 2008 00:14:24 +0000 http://wordpress.org/?v=2.2.2 By: Xaprb http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1394 Xaprb Tue, 08 Aug 2006 19:17:52 +0000 http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1394 <p>Peter of MySQL Performance Blog wrote a very informative article on <a href="http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/">how locking and transaction isolation levels work in InnoDB</a>. Then I asked questions in the comments and he replied. It is well worth reading the article and the comments!</p> Peter of MySQL Performance Blog wrote a very informative article on how locking and transaction isolation levels work in InnoDB. Then I asked questions in the comments and he replied. It is well worth reading the article and the comments!

]]> By: Mark Callaghan http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1343 Mark Callaghan Sat, 05 Aug 2006 17:35:53 +0000 http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1343 <p>InnoDB gets share locks on rows read from the selected table for statements of the form (create|update|delete|insert) .... select ... from .... This is done so that a replica will read the same values as the master for the select. Unfortunately, these share locks are taken when the binlog is disabled, and the set of statements for which the locks are taken has changed from 4.0.20 to 4.0.26 to 4.1 to 5.x (thus the apparent 'randomness'). Depending on the version that you use, innodb_locks_unsafe_for_binlog may prevent the locks from being taken.</p> InnoDB gets share locks on rows read from the selected table for statements of the form (create|update|delete|insert) …. select … from ….
This is done so that a replica will read the same values as the master for the select. Unfortunately, these share locks are taken when the binlog is disabled, and the set of statements for which the locks are taken has changed from 4.0.20 to 4.0.26 to 4.1 to 5.x (thus the apparent ‘randomness’). Depending on the version that you use, innodb_locks_unsafe_for_binlog may prevent the locks from being taken.

]]> By: Jeremy Cole http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1337 Jeremy Cole Sat, 05 Aug 2006 03:36:58 +0000 http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1337 <p>Hi Baron,</p> <p>Fair enough, but mucking with the core server's locking in order to make replication (decidedly, an add-on) work correctly seems like the wrong approach. Perhaps the right approach would be to (at least optionally) allow you to have the INSERT ... SELECT converted into either plain INSERT or optimally LOAD DATA INFILE with the file in-lined in the binlog.</p> <p>Ugliness...</p> <p>Regards,</p> <p>Jeremy</p> Hi Baron,

Fair enough, but mucking with the core server’s locking in order to make replication (decidedly, an add-on) work correctly seems like the wrong approach. Perhaps the right approach would be to (at least optionally) allow you to have the INSERT … SELECT converted into either plain INSERT or optimally LOAD DATA INFILE with the file in-lined in the binlog.

Ugliness…

Regards,

Jeremy

]]> By: Xaprb http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1334 Xaprb Fri, 04 Aug 2006 17:24:56 +0000 http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1334 <p>Hi Jeremy, you're correct that the "select for insert" or "select for update" type of statement is what's acquiring locks. This is necessary for statement-based replication to work correctly, though.</p> Hi Jeremy, you’re correct that the “select for insert” or “select for update” type of statement is what’s acquiring locks. This is necessary for statement-based replication to work correctly, though.

]]> By: Jeremy Cole http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1332 Jeremy Cole Fri, 04 Aug 2006 16:32:02 +0000 http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-1332 <p>Hi Baron,</p> <p>An interesting but missed point in this discussion is that the only reason that InnoDB is trying to acquire a shared read lock is that the CREATE TEMPORARY TABLE upgraded the locking used by that SELECT. If you run the same SELECT, without the CREATE TEMPORARY TABLE, it does not deadlock.</p> <p>I've noticed this before, and in fact complained about it before (at the Users Conference) that InnoDB somewhat "randomly" decides what locking to use for INSERT ... SELECT and CREATE ... SELECT. As far as I can tell, there's no reason that your CREATE ... SELECT should require a shared read lock... multiversioning should allow it to be executed with no locks.</p> <p>Regards,</p> <p>Jeremy</p> Hi Baron,

An interesting but missed point in this discussion is that the only reason that InnoDB is trying to acquire a shared read lock is that the CREATE TEMPORARY TABLE upgraded the locking used by that SELECT. If you run the same SELECT, without the CREATE TEMPORARY TABLE, it does not deadlock.

I’ve noticed this before, and in fact complained about it before (at the Users Conference) that InnoDB somewhat “randomly” decides what locking to use for INSERT … SELECT and CREATE … SELECT. As far as I can tell, there’s no reason that your CREATE … SELECT should require a shared read lock… multiversioning should allow it to be executed with no locks.

Regards,

Jeremy

]]>