Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.11, 11.4
Description
wlad pointed out that the test innodb.log_file_size_online occasionally fails. I was able to reproduce this:
|
11.4 41f54da46f491e968651d5083ff86a78a8635f55 |
innodb.log_file_size_online 'encrypted' w82 [ 42 fail ]
|
Test ended at 2024-11-13 00:48:02
|
|
|
CURRENT_TEST: innodb.log_file_size_online
|
--- mysql-test/suite/innodb/r/log_file_size_online.result 2024-10-03 04:35:31.687366191 -0700
|
+++ mysql-test/suite/innodb/r/log_file_size_online.reject 2024-11-13 00:48:02.582232798 -0800
|
@@ -58,5 +58,5 @@
|
SHOW VARIABLES LIKE 'innodb_log_file_size';
|
Variable_name Value
|
innodb_log_file_size 5242880
|
-FOUND 1 /InnoDB: Resized log to 5\.000MiB/ in mysqld.1.err
|
+NOT FOUND /InnoDB: Resized log to 5\.000MiB/ in mysqld.1.err
|
DROP TABLE t; |
In the server error log, I could see that the server was indeed killed and restarted without that message appearing in the error log. The test case is doing the following:
send SET GLOBAL innodb_log_file_size=5242880; |
|
|
--connect con1,localhost,root
|
send UPDATE t SET b='' WHERE a<10; |
|
|
--connection default
|
reap;
|
SHOW VARIABLES LIKE 'innodb_log_file_size'; |
SELECT global_value FROM information_schema.system_variables |
WHERE variable_name = 'innodb_log_file_size'; |
|
|
--connection con1
|
reap;
|
--disconnect con1
|
--connection default
|
|
|
--let $shutdown_timeout=0
|
--let $restart_parameters=
|
--source include/restart_mysqld.inc
|
|
|
SELECT * FROM t WHERE a<10; |
SELECT COUNT(*),LENGTH(b) FROM t GROUP BY b; |
|
|
SHOW VARIABLES LIKE 'innodb_log_file_size'; |
let SEARCH_PATTERN = InnoDB: Resized log to 5\\.000MiB; |
--source include/search_pattern_in_file.inc |
No difference was reported for the SHOW VARIABLES output, so the log indeed had been resized. The function log_t::write_checkpoint() ends in the following:
resize_target= 0;
|
resize_lsn.store(0, std::memory_order_relaxed);
|
}
|
|
|
log_resize_release();
|
|
|
if (UNIV_LIKELY(resizing <= 1)); |
else if (resizing > checkpoint_lsn) |
buf_flush_ahead(resizing, false); |
else if (resizing_completed) |
ib::info() << "Resized log to " << ib::bytes_iec{resizing_completed} |
<< "; start LSN=" << resizing; |
else |
buf_flush_ahead(end_lsn + 1, false); |
}
|
It would seem to be possible that the SQL connection thread indeed can be notified of the completion (log_sys.resize_lsn=0) and the test case would have a narrow chance to kill the server before ib::info::~info() would write the message to the server error log. I am reluctant to change the code; we should not unnecessarily hold latches during system calls. So, I think that we must remove the check for this output from this test step, and add a separate test step for checking it. We do want to kill and restart the server shortly after resizing and the execution of the UPDATE statement were completed. In this way, some purge of committed transaction history may be executing while the server is being killed.
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
-
- Closed
-