Details
-
Type:
Bug
-
Status: Stalled
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: 10.0.19-galera
-
Fix Version/s: 10.0.22-galera
-
Component/s: None
-
Labels:None
-
Environment:Ubuntu 14.04 64 bit, Docker container
Description
I have several open connections to mariadb server, and some of them, which are older than ~1 day, always return same time when executing select now(); (same for select curtime(), localtime() etc). all of them show some time between current time and time when connection started.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Nirbhay Choubey, could you please look at it from Galera perspective, maybe you will have some ideas what's going on or how to investigate it further.
I don't remember ever having such complaints about stand-alone server, and now we have two, both for Galera 10.0, statistically it's insufficient yet noteworthy.
A very similar issue with no reproducible test case reported here :
https://bugs.launchpad.net/percona-server/+bug/1372501
Can't reproduce. I do not see how the timestamp would freeze for a connection besides SET TIMESTAMP.
Launchpad bug seems to be the same.
About reproducible test case. I don't think we will have one. I have seen this bug only twice in ~6 months. First time on 24.2.2015.
There is trigger mentioned on launchpad. It could be related to it. We have one BEFORE UPDATE and one AFTER INSERT. We also use temporary table in some commands. We don't use procedures, events, views or prepared statements.
Some thoughts out of my code inspection:
- Query start/end time does not actually get updated during query execution.
This shouldn't be the case according to my code analysis. - SELECT NOW() is cached by some proxy and doesn't actually reach the server.
Only possible if all other queries in that connection are cached too, since INFORMATION_SCHEMA.PROCESSLIST also shows stale value. - System call that loads current timestamp returns the same value in this thread (OS bug).
This might be the case: all reporters seem to have Ubuntu, most have 14.04. Can be verified with gdb. - timestamp (and corresponding internal variables) is set after all internally.
Despite of SET timestamp, this can only be done by some third party loaded library/plugin (check galera?). - timestamp (and corresponding internal variables) is set after all externally.
Doesn't seem to be the case, since Com_set_option=1. - Some loss of precision during conversion of start_time.
Value of 1434363000.000000 looks very suspicious. But later it was claimed that value might be 1436786595 as well, which breaks this hypothesis. - Query start/end time is adjusted internally.
This can only be done by some third party loaded library/plugin (check galera?).
So far I see no other reasonable ways to get persistent value out of SELECT NOW(). To get this issue solved we should eliminate all false assumptions.
Is it possible that these connections at some point ran set timestamp = ...?
It would freeze the value.