The InnoDB bootstrap is creating unnecessary log checkpoints
and even invalidating the buffer pool for no reason, making it
necessary to read pages into the buffer pool during bootstrap.
Furthermore, the page cleaner thread attempts to invoke
recv_sys.apply(true), even though most calls were unreachable
starting with commit 685d958e38 (MDEV-14425)
if not earlier.
buf_flush_sync(): Replaced with buf_flush_sync_batch(LSN_MAX),
possibly preceded by recv_sys.apply(true).
buf_pool_t::assert_all_freed(): Assert that buf_pool.mutex is
being held by the caller.
buf_dblwr_t::create(): Evict each doublewrite buffer pool page
immediately from the buffer pool, so that there will be no need
to invoke buf_pool_invalidate(). Also, remove the unnecessary
call to buf_flush_wait_flushed(); there is nothing special about
the doublewrite buffer creation ever since
commit e2c63a7062 (MDEV-38595)
made the redo logging actually crash-safe.
buf_pool_invalidate(): Moved to the same compilation unit with
the only remaining caller, recv_sys_t::apply().
srv_start(): Do not invoke buf_flush_sync(). We already created
an initial checkpoint in log_t::create(lsn_t), and we will create
the final one during shutdown. Together with the simplification of
buf_dblwr_t::create(), this should noticeably speed up the
server bootstrap. Also, simplify the log file rebuild by extending
the critical section of log_sys.latch and buf_pool.flush_list_mutex.
create_log_file(): Assert and assume that both log_sys.latch and
buf_pool.flush_list_mutex were acquired by the caller.
This prevents any race condition with buf_flush_page_cleaner()
when the log is being rebuilt.
srv_prepare_to_delete_redo_log_file(): Invoke recv_sys.apply(true)
before invoking buf_flush_sync_batch(LSN_MAX).
Remove a redundant call to fil_system.sys_space->open(false)
because srv_start() must already have successfully invoked that
in order for us to reach this code path. Remove some duplicated
assertions as well as a redundant call to log_write_up_to() from
the end. If we crash while rebuilding a latest_format log file,
the subsequent startup will perform crash recovery normally.
This avoids a redundant write to the old log.
c380e16597