MDEV-34907 Bogus assertion failure and busy work while parsing FILE_ records
A server that was running with innodb_log_file_size=96M and innodb_buffer_pool_size=6M had inserted some data into a table that was subsequently dropped. When the server was killed and restarted, an assertion failed in recv_sys_t::parse() while a FSP_SIZE change was unnecessarily being processed during the skip_the_rest: loop in recv_scan_log(). The ib_logfile0 contents was as follows: 1. The checkpoint start LSN points to the start of some mini-transaction. 2. There may be log records for modifying files for which a FILE_MODIFY had been written before the checkpoint. These records were "purged" by advancing the checkpoint. 3. At some point during the initial parsing with store=true the space reserved for recv_sys.pages will run out and recv_scan_log() would switch to the skip_the_rest: mode. 4. We encounter a log record for extending a tablespace that will be deleted a bit later. This would trip the bogus debug assertion. 5. Later on, there would be a FILE_DELETE record for this tablespace. 6. The checkpoint end LSN points to a possibly empty sequence of FILE_MODIFY records and a FILE_CHECKPOINT record. Recovery had parsed these records first, before rewinding to the checkpoint start LSN. 7. There could be further records following the FILE_CHECKPOINT record. Recovery will process all records until an inconsistency is found and it is assumed that the end of the circular ib_logfile0 was reached. recv_sys_t::parse(): For the template instantiation with store=false, remove a debug assertion that could fail in a multi-batch recovery, while recv_scan_log(false) would be in the skip_the_rest: loop. It is very well possible that we have not encountered all FILE_ records yet, and therefore we should not complain about unknown tablespaces. Reviewed by: Debarun Banerjee
Showing
Please register or sign in to comment