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! Mon, 13 May 2013 05:55:40 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: Jeroen Meijer http://www.xaprb.com/blog/2006/08/03/a-little-known-way-to-cause-a-database-deadlock/#comment-19874 Jeroen Meijer Fri, 10 Feb 2012 10:34:49 +0000 http://www.xaprb.com/blog/?p=207#comment-19874 For mysql you may want to add a SELECT SLEEP(5); between the select and update statements.

]]> 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

]]> 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.

]]> 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 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 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.

]]>