Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.2, 10.3, 10.4, 10.5, 10.6
-
None
Description
InnoDB holds dict_sys mutex while doing file i/o operation during creation of table.
In fil_ibd_create():
if (ulint zip_size = fil_space_t::zip_size(flags)) {
|
page_zip_des_t page_zip;
|
page_zip_set_size(&page_zip, zip_size);
|
page_zip.data = page + srv_page_size;
|
#ifdef UNIV_DEBUG
|
page_zip.m_start = 0;
|
#endif /* UNIV_DEBUG */
|
page_zip.m_end = 0;
|
page_zip.m_nonempty = 0;
|
page_zip.n_blobs = 0;
|
|
|
buf_flush_init_for_writing(NULL, page, &page_zip, false);
|
|
|
*err = os_file_write(IORequestWrite, path, file,
|
page_zip.data, 0, zip_size);
|
} else {
|
buf_flush_init_for_writing(NULL, page, NULL,
|
fil_space_t::full_crc32(flags));
|
|
|
*err = os_file_write(IORequestWrite, path, file,
|
page, 0, srv_page_size);
|
}
|
|
|
if (!os_file_flush(file)) {
|
ib::error() << "File flush of tablespace '"
|
<< path << "' failed";
|
*err = DB_ERROR;
|
goto err_exit;
|
}
|
If we remove the page0 write and flushing the file then InnoDB should handle this scenario during recovery. Right now, InnoDB does the validation of page0 while parsing the FILE redo log records.
InnoDB should defer these tablespace as uninitialized if it encounters zero-filled page 0
and recover page0 of these tablespace before recovering any other pages of these tablespace. This is the idea right now. It could change when we're debuggging encrypted and compressed tablespace.
Attachments
Issue Links
- blocks
-
MDEV-14481 Execute InnoDB crash recovery in the background
-
- Closed
-
-
-
- Closed
-
- causes
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-