main.log_tables-big unstable on loaded hosts
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
||||
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.5 |
Won't Fix
|
Low
|
Unassigned | |||
5.6 |
Won't Fix
|
Low
|
Unassigned | |||
5.7 |
Fix Released
|
Low
|
Laurynas Biveinis |
Bug Description
Copy of https:/
[3 Mar 14:25] Laurynas Biveinis
Description:
main.log_tables-big w4 [ fail ]
Test ended at 2016-03-02 10:44:16
CURRENT_TEST: main.log_tables-big
--- /mnt/workspace/
+++ /mnt/workspace/
@@ -24,6 +24,7 @@
0
select if (query_time between '00:01:40' and '00:01:50', 'OK', 'WRONG') as qt, sql_text from mysql.slow_log;
qt sql_text
+WRONG truncate table mysql.slow_log
OK select get_lock('bug27638', 101)
select release_lock('bug27638');
release_lock('bug27638')
The gist of the testcase is
truncate table mysql.slow_log;
select get_lock('bug27638', 2);
select if (query_time between '00:00:01' and '00:00:10', 'OK', 'WRONG') as qt, sql_text from mysql.slow_log;
... repeated with different get_lock timeouts ...
Two things can go wrong here, on a very loaded host:
1) truncate table may take >1 s to complete, getting logged into slow log table as in the output above
2) get_lock may take than timeout + 10 s to complete
How to repeat:
Testcase analysis. Not sure if MTR --repeat --parallel high on this testcase alone will help to repeat as the testcase spends most of the time sleeping.
Suggested fix:
1) add WHERE sql_text = "get_lock ... " to the mysql.slow_log selects
2) test only the lower time bound
tags: | added: ci upstream |
https:/ /github. com/percona/ percona- server/ pull/399