percona_slow_query_log_rate fails sporadically
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
Low
|
Yura Sorokin | ||
5.5 |
Fix Released
|
Low
|
Yura Sorokin | ||
5.6 |
Fix Released
|
Low
|
Yura Sorokin |
Bug Description
percona_
_StringException: Text attachment: traceback
------------
Comment:
Logfile:
CURRENT_TEST: main.percona_
--- /mnt/workspace/
+++ /mnt/workspace/
@@ -24,7 +24,7 @@
connection_three
[log_stop.inc] percona.
[log_grep.inc] file: percona.
-[log_grep.inc] sum: 2
+[log_grep.inc] sum: 1
[log_grep.inc] zero: 2
SET GLOBAL debug="
SET GLOBAL log_slow_
mysqltest: Result content mismatch
------------
The problem turned out to be with disabling slow query log from one connection while other ones executing "SELECT 'something_xxx'", although already sent the result back to the client, have not written these statements to the slog
yet.
In other words, when the thread executing "SELECT 'connection_xxx'" pauses somewhere in "dispatch_ command( )" (sql_parse.cc) after "thd->protocol- >end_statement( )" but before "log_slow_ statement( )", the other thread executes "SET GLOBAL slow_query_log=0" and therefore closes slow query log file. When the first thread resumes, and executes "log_slow_ statement( )", nothing happens as the slow query log file is already closed.
The fix could be in executing one dummy statement in each "SELECT" connection after the while loop to make sure that these statements are 100% processed (including writing to the slow query log).