mirror of
https://github.com/MariaDB/server.git
synced 2025-08-10 20:41:44 +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. |
||
|---|---|---|
| .. | ||
| archive | ||
| blackhole | ||
| columnstore | ||
| connect | ||
| csv | ||
| example | ||
| federated | ||
| federatedx | ||
| heap | ||
| innobase | ||
| maria | ||
| mroonga | ||
| myisam | ||
| myisammrg | ||
| oqgraph | ||
| perfschema | ||
| rocksdb | ||
| sequence | ||
| sphinx | ||
| spider | ||
| test_sql_discovery | ||