| Bug #33988 | "Locked" state of the thread can be misleading | ||
|---|---|---|---|
| Submitted: | 22 Jan 2008 18:43 | Modified: | 5 May 2009 9:29 |
| Reporter: | SINISA MILIVOJEVIC | Email Updates: | |
| Status: | Won't fix | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S3 (Non-critical) |
| Version: | 5.0, 5.1 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[22 Jan 2008 18:43]
MySQL Verification Team
My analysis was fully confirmed by Ingo Struwing. Instead of "Locked", status should be "Waiting for table(s)".
[5 May 2009 9:29]
Sergei Golubchik
No bug here, thd->proc_info is reset after the loop.
Description: This is an incongruency in our locking code. Here it is, from lock.cc: thd->proc_info="Table lock"; thd->locked=1; /* Copy the lock data array. thr_multi_lock() reorders its contens. */ memcpy(sql_lock->locks + sql_lock->lock_count, sql_lock->locks, sql_lock->lock_count * sizeof(*sql_lock->locks)); /* Lock on the copied half of the lock data array. */ rc= thr_lock_errno_to_mysql[(int) thr_multi_lock(sql_lock->locks + sql_lock->lock_count, sql_lock->lock_count, thd->lock_id)]; if (rc > 1) /* a timeout or a deadlock */ { my_error(rc, MYF(0)); my_free((gptr) sql_lock,MYF(0)); sql_lock= 0; break; } thd->locked is not cleared in the block starting with : if (rc > 1) ... This has a consequence that many threads are declared "Locked" in SHOW PROCESSLIST, which confuses customers a lot. How to repeat: Inapplicable Suggested fix: if (rc > 1) /* a timeout or a deadlock */ { my_error(rc, MYF(0)); my_free((gptr) sql_lock,MYF(0)); sql_lock= 0; thd->locked= 0; break; }