Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3.10, 10.4.0, 10.2.19
Description
A test occasionally fails like this:
|
10.4 2dd6cd5f15f9996f38b4fcba890a237d69041d5a |
innodb.undo_truncate_recover '2,4k,innodb' w28 [ fail ]
|
Test ended at 2018-11-27 09:27:05
|
|
|
CURRENT_TEST: innodb.undo_truncate_recover
|
…
|
2018-11-27 9:27:03 0 [Note] InnoDB: Opened 2 undo tablespaces
|
2018-11-27 9:27:03 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=22827480
|
2018-11-27 9:27:04 0 [Note] InnoDB: Starting a batch to recover 3004 pages from redo log.
|
mysqld: /mariadb/10.4/storage/innobase/log/log0recv.cc:258: void recv_addr_trim(ulint, unsigned int, lsn_t): Assertion `file->is_open()' failed.
|
In a release build, the impact of this would be calling ftruncate() or SetFilePointerEx() on OS_FILE_CLOSED, and thus failing to shrink the file:
fil_node_t* file = UT_LIST_GET_FIRST(space->chain);
|
ut_ad(file->is_open());
|
os_file_truncate(file->name, file->handle,
|
os_offset_t(pages) << srv_page_size_shift,
|
true); |
There is no guarantee that the undo tablespace file would be open at this point. srv_undo_tablespace_open() is opening and immediately closing the file, without assigning fil_node_t::handle.
Attachments
Issue Links
- is caused by
-
-
- Closed
-