mirror of
https://github.com/MariaDB/server.git
synced 2025-08-24 19:31:36 +02:00
4d37b1c4b9
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. |
||
|---|---|---|
| .. | ||
| buf0buddy.cc | ||
| buf0buf.cc | ||
| buf0checksum.cc | ||
| buf0dblwr.cc | ||
| buf0dump.cc | ||
| buf0flu.cc | ||
| buf0lru.cc | ||
| buf0rea.cc | ||