Bug #22412 | Events: strange locking behavior | ||
---|---|---|---|
Submitted: | 16 Sep 2006 8:23 | Modified: | 28 Sep 2006 10:41 |
Reporter: | Dmitry Lenev | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Stored Routines | Severity: | S3 (Non-critical) |
Version: | 5.1.12-debug-bk | OS: | Linux (Linux Suse 10.1) |
Assigned to: | Andrey Hristov | CPU Architecture: | Any |
[16 Sep 2006 8:23]
Dmitry Lenev
[16 Sep 2006 11:04]
Valeriy Kravchuk
Thank you for a problem report. Verified just as described with 5.1.12-BK (ChangeSet@1.2330, 2006-09-16 07:19:42+02:00) on Linux.
[28 Sep 2006 10:40]
Andrey Hristov
Seems to me like not a bug. 1. According to mysqladmin debug, the SELECT is low priority and the INSERTs are high priority. Moreover, the INSERTs sleep for one second and more are spawned than finishing. This keeps a constant list of high priority writing threads which do not allow the SELECT to finish. - Changing the table type to Innodb solves the problem - Stating explicitly that the INSERT should be LOW_PRIORITY and the SELECT should be HIGH_PRIORITY solves the problem - the SELECT query returns, not immediately but the response time is under 1s.
[28 Sep 2006 10:41]
Andrey Hristov
Thread database.table_name Locked/Waiting Lock_type 0 mysql.slow_log Locked - write Concurrent insert lock 0 mysql.general_log Locked - write Concurrent insert lock 1 db2.t_24 Waiting - read Low priority read lock 10 db2.t_24 Locked - write High priority write lock