MySQL Bugs: #59757: 35396 - very large query times, this bug came back?

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:	None
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

Description:
Bug 35396 appears to have re-appeared in 5.1.52; the bug report says it was patched in 5.1.32

http://bugs.mysql.com/bug.php?id=35396

# 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:
hurm...

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?...

Probably a duplicate of this one : http://bugs.mysql.com/bug.php?id=63524

We had a regression bug #63524. Please, check if this problem is still repeatable with 5.1.63+ (where that regression should be fixed).