Bug #59757 35396 - very large query times, this bug came back?
Submitted: 26 Jan 2011 19:33 Modified: 4 Jun 2012 13:53
Reporter: Daniel Lo Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server Severity:S4 (Feature request)
Version:5.1.52 OS:Linux (unknown-linux-gnu (x86_64))
Assigned to: CPU Architecture:Any
Tags: large, mysql slow query, Query_time, slow

[26 Jan 2011 19:33] Daniel Lo
Bug 35396 appears to have re-appeared in 5.1.52; the bug report says it was patched in 5.1.32


# from the bug report
Pushed into 5.1.32 (revid:joro@sun.com-20090203090549-gos3v4320vimrzg6) (version source
revid:joro@sun.com-20090129124935-mfv4pddc8exvs3nz) (merge vers: 5.1.32) (pib:6)

Here is the sample from our logs yesterday: (some info censored)

# User@Host: ..censored..[..censored..] @  [..censored..]
# Query_time: 18446744073709.550781  Lock_time: 0.000037 Rows_sent: 0  Rows_examined: 0
SET timestamp=1295936401;
SELECT ...censored..;
# User@Host: ..censored..[..censored..] @  [..censored..]
# Query_time: 18446744073709.550781  Lock_time: 0.000049 Rows_sent: 0  Rows_examined: 0
SET timestamp=1295936401;
SELECT ...censored..;

Following the previous post, I examined the date and it is exactly when we run ntpdate.  I am adjusting our ntpdate to run less frequently and I will see how that goes.

What a weird bug to encounter. :)

How to repeat:
[9 Sep 2011 15:00] Richard Lynch
This is happening for me also, in 5.1.52-ius-log, in the slow query log.

Are these really slow queries with bad reporting, or a bogus false positive caused by the clock reset?...
[4 Jun 2012 13:53] Arnaud Adant
Probably a duplicate of this one : http://bugs.mysql.com/bug.php?id=63524
[4 Jun 2012 13:53] Valeriy Kravchuk
We had a regression bug #63524. Please, check if this problem is still repeatable with 5.1.63+ (where that regression should be fixed).