Marko Mäkelä added a comment - 2019-07-25 11:02 The main idea of the Oracle fix is related to the limiting the atomicity of fts_sync_write_words() . This part of the fix wrongly assumes that the system clock is monotonic (never moving backwards): ulint cache_lock_time = ut_time() - sync_start_time; if (cache_lock_time > lock_threshold) { Similar to our MDEV-14154 changes, in particular the one that removed bogus assertions , we should use something like this: ulint interval = ulint( time (NULL) - start_time); if (lint(interval) < 0 || interval > time_limit)) { That is, we will time out if the time moved backwards. Because time(NULL) may have a much lower overhead than my_interval_timer() or other monotonic clock sources and because the precision of one second suffices here, I think that we should stick to time(NULL) . Anyway, the main idea of the Oracle change is to extend the innodb_fatal_semaphore_wait_threshold ( srv_fatal_semaphore_wait_threshold ) if a fts_sync_table() operation from outside the optimizer thread is taking longer. That is, it will prevent the operation of the InnoDB built-in watchdog, instead of actually fixing the root cause of the problem.

Thirunarayanan Balathandayuthapani added a comment - 2019-10-03 13:15 To fix this issue, InnoDB should have multiple fts_optimize_threads to process the messages from the queue. By using multiple fts_optimize_threads, InnoDB can reduce the cache size significantly and it can make lesser wait time for DDL/dict_table_mem_free() for fts_optimize_remove_table() .