Bug #71365 | "Waiting for table level lock" thread state is not explained properly | ||
---|---|---|---|
Submitted: | 13 Jan 2014 16:24 | Modified: | 1 Mar 2016 17:46 |
Reporter: | Valeriy Kravchuk | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.5, 5.6 | OS: | Any |
Assigned to: | Paul DuBois | CPU Architecture: | Any |
Tags: | missing manual, thread state |
[13 Jan 2014 16:24]
Valeriy Kravchuk
[20 Jan 2014 21:06]
MySQL Verification Team
Thank you for the bug report.
[1 Mar 2016 17:46]
Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly. re: "1. Does the above mean that this state can happen only with external locks enabled?" No, since a system lock was obtained, and that may have waited for either internal or external lock. I will modify "Table lock" description accordingly. re: "2. Does this kind of waiting happens only for MyISAM table?" In the state description, no storage engine is mentioned or implied, so, no. Also, for some of the metadata lock states, no table (and thus no storage engine) is involved. re: "3. Why thread may have to wait for this lock? What may block it from getting it immediately? When the lock of this kind is released? Where one can get more information about the lock wait and what exact session blocks? And so on..." I'll mention that you can use the Performance Schema lock tables to see what's blocking what. (http://dev.mysql.com/doc/refman/5.7/en/performance-schema-lock-tables.html) Also, http://dev.mysql.com/doc/refman/5.7/en/internal-locking.html provides information about related status variables. I'll cross reference that as well.