Bug #81467 innodb_fts.sync_block test unstable due to slow query log nondeterminism
Submitted: 17 May 2016 14:33 Modified: 18 May 2016 9:43
Reporter: Alexey Kopytov Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Tests Severity:S3 (Non-critical)
Version:5.7, 5.7.12 OS:Any
Assigned to: CPU Architecture:Any

[17 May 2016 14:33] Alexey Kopytov
Description:
The innodb_fts.sync_block MTR test fails sporadically on loaded
machines, because it relies on specific content in the slow query log
and filters only by execution time, and thus assumes specific execution
time.

Here's an example:

@@ -30,6 +30,11 @@
 # slow log results should only contain INSERT INTO t1.
 SELECT sql_text FROM mysql.slow_log WHERE query_time >= '00:00:02';
 sql_text
+CREATE TABLE t1 (
+FTS_DOC_ID BIGINT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
+title VARCHAR(200),
+FULLTEXT(title)
+) ENGINE = InnoDB
 INSERT INTO t1(title) VALUES('mysql database')
 SET GLOBAL debug="-d,fts_instrument_sync_debug,fts_instrument_sync_sleep";
 TRUNCATE TABLE mysql.slow_log;

So we are interested in all queries that took 2 or more seconds. In this
case, the previosly executed CREATE TABLE took more time than on
developer's machine where the test was recorded, hence the failure.

How to repeat:
Read the innodb_fts.sync_block test.

Suggested fix:
Filter "interesting" queries based on some additional criteria
(e.g. specific substrings) rather than just execution time as most other
slow query log tests do.
[18 May 2016 8:34] MySQL Verification Team
Hello Alexey,

Thank you for the report.

Thanks,
Umesh
[18 May 2016 9:43] Alexey Kopytov
Changing the category.