mirror of
https://github.com/MariaDB/server.git
synced 2025-01-29 02:05:57 +01:00
c391fb1ff1
If InnoDB is killed in such a way that there had been no writes to a newly resized ib_logfile101 after it replaced ib_logfile0 in log_t::write_checkpoint(), it is possible that recovery will accidentally interpret some garbage at the end of the log as valid. log_t::write_buf(): To prevent the corruption, write an extra NUL byte at the end of log_sys.resize_buf, like we always did for the main log_sys.buf. To remove some conditional branches from a time critical code path, we instantiate a separate template for the rare case that the log is being resized. Define as __attribute__((always_inline)) so that this will be inlined also in the rare case the log is being resized. log_t::writer: Pointer to the current implementation of log_t::write_buf(). For quick access, this is located in the same cache line with log_sys.latch, which protects it. log_t::writer_update(): Update log_sys.writer. log_t::resize_write_buf(): Remove ATTRIBUTE_NOINLINE ATTRIBUTE_COLD. Now that log_t::write_buf() will be instantiated separately for the rare case of log resizing being in progress, there is no need to forbid this code from being inlined. Thanks to Thirunarayanan Balathandayuthapani for finding the root cause of this bug and suggesting the fix of writing an extra NUL byte. Reviewed by: Debarun Banerjee |
||
|---|---|---|
| .. | ||
| archive | ||
| blackhole | ||
| columnstore | ||
| connect | ||
| csv | ||
| example | ||
| federated | ||
| federatedx | ||
| heap | ||
| innobase | ||
| maria | ||
| mroonga | ||
| myisam | ||
| myisammrg | ||
| oqgraph | ||
| perfschema | ||
| rocksdb | ||
| sequence | ||
| sphinx | ||
| spider | ||
| test_sql_discovery | ||