| Bug #56836 | GET_LOCK() timeout behaves differently on differing platforms | ||
|---|---|---|---|
| Submitted: | 17 Sep 2010 9:22 | Modified: | 29 Jul 2014 15:15 |
| Reporter: | Mat Gadd | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Locking | Severity: | S3 (Non-critical) |
| Version: | 5.1.50, 5.5.37, 5.6.17 | OS: | Any (See description) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | locking, server | ||
[17 Sep 2010 9:54]
Valeriy Kravchuk
Please, check if the behavior is still different with current version, 5.1.50.
[17 Sep 2010 13:06]
Mat Gadd
Confirmed under 5.1.50.
mysql> SELECT 'Windows', @@version, GET_LOCK('test', -1);
+---------+----------------------+----------------------+
| Windows | @@version | GET_LOCK('test', -1) |
+---------+----------------------+----------------------+
| Windows | 5.1.50-community-log | 1 |
+---------+----------------------+----------------------+
1 row in set (0.00 sec)
mysql> SELECT 'Windows', @@version, GET_LOCK('test', -1);
+---------+----------------------+----------------------+
| Windows | @@version | GET_LOCK('test', -1) |
+---------+----------------------+----------------------+
| Windows | 5.1.50-community-log | 1 |
+---------+----------------------+----------------------+
1 row in set (18.92 sec)
mysql> SELECT 'FreeBSD', @@version, GET_LOCK('test', -1);
+---------+-----------+----------------------+
| FreeBSD | @@version | GET_LOCK('test', -1) |
+---------+-----------+----------------------+
| FreeBSD | 5.1.50 | 1 |
+---------+-----------+----------------------+
1 row in set (0.00 sec)
mysql> SELECT 'FreeBSD', @@version, GET_LOCK('test', -1);
+---------+-----------+----------------------+
| FreeBSD | @@version | GET_LOCK('test', -1) |
+---------+-----------+----------------------+
| FreeBSD | 5.1.50 | 0 |
+---------+-----------+----------------------+
1 row in set (0.00 sec)
[17 Sep 2010 14:45]
Mat Gadd
Changed title, as it's now been confirmed on 5.1.50.
[14 Mar 2014 19:19]
Sveta Smirnova
Thank you for the report. I can not repeat described behavior on FreeBSD with version 5.5 and up. Please upgrade.
[14 Mar 2014 19:22]
Sveta Smirnova
Actually current behavior when timeout is negative is confusing and you are correct that this should be at least documented.
[29 Jul 2014 15:15]
Paul DuBois
Noted in 5.5.8 changelog. Previously, a negative timeout value to GET_LOCK() was interpreted as infinite timeout, but only on Windows. This is now the case on all platforms.
Description: After some experimenting on my Windows Vista development machine running MySQL 5.1.31, I found that passing -1 as the timeout to GET_LOCK() would cause it to wait a very long time (I presume indefinitely, or near MAX_INT seconds). I proceeded to use this in conjunction with the event scheduler to make sure only one heavy scheduled task would run at a time. However, once deployed to our testing server running 5.1.42 on FreeBSD, GET_LOCK(str, -1) returns immediately! I'm not sure if this "bug" would be fixed, but the documentation makes no mention of negative timeout values at all. How to repeat: On Windows: Connection1: mysql> SELECT GET_LOCK('test', -1); +----------------------+ | GET_LOCK('test', -1) | +----------------------+ | 1 | +----------------------+ 1 row in set (0.00 sec) Connection 2 (closing Connection 1 after some time): mysql> SELECT GET_LOCK('test', -1); +----------------------+ | GET_LOCK('test', -1) | +----------------------+ | 1 | +----------------------+ 1 row in set (41.06 sec) On FreeBSD: Connection 1: mysql> SELECT GET_LOCK('test', -1); +----------------------+ | GET_LOCK('test', -1) | +----------------------+ | 1 | +----------------------+ 1 row in set (0.00 sec) Connection 2: mysql> SELECT GET_LOCK('test', -1); +----------------------+ | GET_LOCK('test', -1) | +----------------------+ | 0 | +----------------------+ 1 row in set (0.00 sec) Suggested fix: Either make all platforms behave the same, or if it's a difference inherent to the versions I'm running, document the behaviour. At the very least, update the documentation to state that negative values behaviour is inconsistent.