• Marko Mäkelä's avatar
    MDEV-33112 innodb_undo_log_truncate=ON is blocking page write · 3613fb2a
    Marko Mäkelä authored
    When innodb_undo_log_truncate=ON causes an InnoDB undo tablespace
    to be truncated, we must guarantee that the undo tablespace will
    be rebuilt atomically: After mtr_t::commit_shrink() has durably
    written the mini-transaction that rebuilds the undo tablespace,
    we must not write any old pages to the tablespace.
    
    To guarantee this, in trx_purge_truncate_history() we used to
    traverse the entire buf_pool.flush_list in order to acquire
    exclusive latches on all pages for the undo tablespace that
    reside in the buffer pool, so that those pages cannot be written
    and will be evicted during mtr_t::commit_shrink(). But, this
    traversal may interfere with the page writing activity of
    buf_flush_page_cleaner(). It would be better to lazily discard
    the old pages of the truncated undo tablespace.
    
    fil_space_t::is_being_truncated, fil_space_t::clear_stopping(): Remove.
    
    fil_space_t::create_lsn: A new field, identifying the LSN of the
    latest rebuild of a tablespace.
    
    buf_page_t::flush(), buf_flush_try_neighbors(): Evict pages whose
    FIL_PAGE_LSN is below fil_space_t::create_lsn.
    
    mtr_t::commit_shrink(): Update fil_space_t::create_lsn and
    fil_space_t::size right before the log is durably written and the
    tablespace file is being truncated.
    
    fsp_page_create(), trx_purge_truncate_history(): Simplify the logic.
    
    Reviewed by: Thirunarayanan Balathandayuthapani, Vladislav Lesin
    Performance tested by: Axel Schwenke
    Correctness tested by: Matthias Leich
    3613fb2a
fsp0fsp.cc 93.7 KB