Bug #66906 | Innodb_row_lock_time_max seems to have an overflow | ||
---|---|---|---|
Submitted: | 21 Sep 2012 12:16 | Modified: | 16 Apr 2013 12:24 |
Reporter: | Oli Sennhauser | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
Version: | 5.5.24, 5.5.30 | OS: | Linux |
Assigned to: | CPU Architecture: | Any |
[21 Sep 2012 12:16]
Oli Sennhauser
[14 Dec 2012 19:56]
Sveta Smirnova
Thank you for the report. Verified as described using code analysis. Problem is in file storage/innobase/srv/srv0srv.c : 1711 if (thr->lock_state == QUE_THR_LOCK_ROW) { 1712 if (ut_usectime(&sec, &ms) == -1) { 1713 finish_time = -1; 1714 } else { 1715 finish_time = (ib_int64_t) sec * 1000000 + ms; 1716 } 1717 1718 diff_time = (ulint) (finish_time - start_time); 1719 1720 srv_n_lock_wait_current_count--; 1721 srv_n_lock_wait_time = srv_n_lock_wait_time + diff_time; 1722 if (diff_time > srv_n_lock_max_wait_time && 1723 /* only update the variable if we successfully 1724 retrieved the start and finish times. See Bug#36819. */ 1725 start_time != -1 && finish_time != -1) { 1726 srv_n_lock_max_wait_time = diff_time; 1727 }
[16 Apr 2013 12:24]
Bugs System
Added a changelog entry for 5.5.32, 5.7.2: An overflow would occur for "innodb_row_lock_time_max" and "innodb_row_lock_current_waits". This fix modifies code logic in "storage/innobase/srv/srv0srv.c".