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, 09 Feb 2012 20:41:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: thushara http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-18906 thushara Sat, 13 Nov 2010 22:29:06 +0000 http://www.xaprb.com/blog/?p=207#comment-18906 clear post. i used this to get a good understanding on the concept. i had a different problem of multiple concurrent inserts deadlocking without a select doing a table scan. it seems to be a similar issue: http://thushw.blogspot.com/2010/11/mysql-deadlocks-with-concurrent-inserts.html clear post. i used this to get a good understanding on the concept. i had a different problem of multiple concurrent inserts deadlocking without a select doing a table scan. it seems to be a similar issue:

http://thushw.blogspot.com/2010/11/mysql-deadlocks-with-concurrent-inserts.html

]]> By: aliende http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-18213 aliende Tue, 27 Apr 2010 16:40:33 +0000 http://www.xaprb.com/blog/?p=207#comment-18213 Wonderful! This clearly shows how the gap locking works. This was not so clear to me when i was reading the MySQL- manual on locking. Wonderful! This clearly shows how the gap locking works. This was not so clear to me when i was reading the MySQL- manual on locking.

]]> 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/?p=207#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/?p=207#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/?p=207#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

]]>