mariadb/storage/innobase/buf
Marko Mäkelä 4d37b1c4b9 MDEV-36886 log_t::get_lsn_approx() isn't lower bound
If the execution of the two reads in log_t::get_lsn_approx() is
interleaved with concurrent writes of those fields in
log_t::write_buf() or log_t::persist(), the returned approximation
will be an upper bound. If log_t::append_prepare_wait() is pending,
the approximation could be a lower bound.

We must adjust each caller of log_t::get_lsn_approx() for the
possibility that the return value is larger than
MAX(oldest_modification) in buf_pool.flush_list.

af_needed_for_redo(): Add a comment that explains why the glitch
is not a problem.

page_cleaner_flush_pages_recommendation(): Revise the logic for
the unlikely case cur_lsn < oldest_lsn.  The original logic would have
invoked af_get_pct_for_lsn() with a very large age value, which
would likely cause an overflow of the local variable lsn_age_factor,
and make pct_for_lsn a "random number".  Based on that value,
total_ratio would be normalized to something between 0.0 and 1.0.
Nothing extremely bad should have happened in this case;
the innodb_io_capacity_max should not be exceeded.
2025-05-28 14:44:43 +03:00
..
buf0buddy.cc MDEV-36781: Assertion i < BUF_BUDDY_SIZES failed in buf_buddy_shrink() 2025-05-13 12:27:46 +03:00
buf0buf.cc MDEV-36868: Inconsistency when shrinking innodb_buffer_pool_size 2025-05-28 13:33:06 +03:00
buf0checksum.cc Cleanup: Replace ut_crc32c(x,y) with my_crc32c(0,x,y) 2022-01-21 16:13:04 +02:00
buf0dblwr.cc MDEV-21923: LSN allocation is a bottleneck 2025-04-10 13:02:17 +03:00
buf0dump.cc MDEV-29445: Reimplement SET GLOBAL innodb_buffer_pool_size 2025-03-26 17:05:44 +02:00
buf0flu.cc MDEV-36886 log_t::get_lsn_approx() isn't lower bound 2025-05-28 14:44:43 +03:00
buf0lru.cc MDEV-36781: Assertion i < BUF_BUDDY_SIZES failed in buf_buddy_shrink() 2025-05-13 12:27:46 +03:00
buf0rea.cc MDEV-29445: Reimplement SET GLOBAL innodb_buffer_pool_size 2025-03-26 17:05:44 +02:00