Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL), 11.3(EOL), 11.4
Description
When mleich tested a port of MDEV-27812 to MariaDB Enterprise Server 10.6, he noticed that an attempt to execute multiple concurrent SET GLOBAL innodb_log_file_size=...; would result in long waits. The culprit turned out to be an incorrect choice of a condition variable in a timed wait:
diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
|
index 407834f2008..06af558a2e7 100644
|
--- a/storage/innobase/handler/ha_innodb.cc
|
+++ b/storage/innobase/handler/ha_innodb.cc
|
@@ -18452,7 +18452,7 @@ static void innodb_log_file_size_update(THD *thd, st_mysql_sys_var*,
|
const bool in_progress(buf_pool.get_oldest_modification(LSN_MAX) <
|
log_sys.resize_in_progress());
|
if (in_progress)
|
- my_cond_timedwait(&buf_pool.do_flush_list,
|
+ my_cond_timedwait(&buf_pool.done_flush_list,
|
&buf_pool.flush_list_mutex.m_mutex, &abstime);
|
mysql_mutex_unlock(&buf_pool.flush_list_mutex);
|
if (!log_sys.resize_in_progress()) |
The condition variable buf_pool.done_flush_list is broadcast by the buf_flush_page_cleaner() after the end of each batch, which is when the log checkpoint can advance and where any log resizing may be completed. The purpose of the condition variable buf_pool.do_flush_list is to wake up the buf_flush_page_cleaner() thread because there is work to do. If no thread is signaling that condition variable, this loop could unnecessarily wait for up to 5 seconds too long for the log resizing to be completed. By consuming signals it could also prevent the buf_flush_page_cleaner() thread from waking up.
Attachments
Issue Links
- is caused by
-
MDEV-27812 Allow innodb_log_file_size to change without server restart
- Closed