• Marko Mäkelä's avatar
    MDEV-26445 innodb_undo_log_truncate is unnecessarily slow · f5794e1d
    Marko Mäkelä authored
    trx_purge_truncate_history(): Do not force a write of the undo tablespace
    that is being truncated. Instead, prevent page writes by acquiring
    an exclusive latch on all dirty pages of the tablespace.
    
    fseg_create(): Relax an assertion that could fail if a dirty undo page
    is being initialized during undo tablespace truncation (and
    trx_purge_truncate_history() already acquired an exclusive latch on it).
    
    fsp_page_create(): If we are truncating a tablespace, try to reuse
    a page that we may have already latched exclusively (because it was
    in buf_pool.flush_list). To some extent, this helps the test
    innodb.undo_truncate,16k to avoid running out of buffer pool.
    
    mtr_t::commit_shrink(): Mark as clean all pages that are outside the
    new bounds of the tablespace, and only add the newly reinitialized pages
    to the buf_pool.flush_list.
    
    buf_page_create(): Do not unnecessarily invoke change buffer merge on
    undo tablespaces.
    
    buf_page_t::clear_oldest_modification(bool temporary): Move some
    assertions to the caller buf_page_write_complete().
    
    innodb.undo_truncate: Use a bigger innodb_buffer_pool_size=24M.
    On my system, it would otherwise hang 1 out of 1547 attempts
    (on the 40th repeat of innodb.undo_truncate,16k).
    Other page sizes were not affected.
    f5794e1d
fsp0fsp.cc 88.3 KB