| 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
