| Bug #13035 | Locks acquired with get_lock() persisting, even after MySQL thread has exited | ||
|---|---|---|---|
| Submitted: | 7 Sep 2005 12:05 | Modified: | 13 Sep 2005 17:26 |
| Reporter: | Adam Newby | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | ysql-4.1.11-Debian_4 (Source distributio | OS: | Linux (Linux 2.4.24) |
| Assigned to: | CPU Architecture: | Any | |
[7 Sep 2005 14:48]
Gleb Paharenko
Hi! I'm sure the developers will find it, but at least something wrong with the GET_LOCK() code. See: http://bugs.mysql.com/bug.php?id=10374
[13 Sep 2005 17:26]
Ralf Gebhardt
Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thank you for your interest in MySQL. Additional info: Please let us know if you think that http://bugs.mysql.com/bug.php?id=10374 is not be a dublicate to your bug report
Description: We have distributed applications which make extensive use of the get_lock() function to acquire a system-wide lock. Occasionally, all copies of a given application block attempting to acquire a lock on the same lock string. Using is_used_lock() reports that the lock is held by a particular thread ID. In one instance, this thread ID did not exist. In another instance, it did exist, but after killing that thread, is_used_lock() still reported the same (now non-existent) thread as holding the lock. Here is an example: output from 'mysql newsnow -unewsnow -e "select is_used_lock('1 1 11')"': is_used_lock('1 1 11') 1111166 See the attached output from 'mysqladmin processlist' at the same time - note that the above thread ID is not listed. How to repeat: We're not sure at this point how to reproduce this problem. Suggested fix: No fix identified.