The next logical step is to remove the parameter altogether, along with any code that would create the change buffer or add records to it. An attempt to downgrade to an earlier version will be caught and prevented by
In order to be able to simplify the buffer pool interfaces, upgrading will be split in two parts: First, check if an upgrade is needed. If it is, we will apply all redo log, possibly upgrade the redo log to the current format, and then attempt to upgrade the change buffer:
- Apply any buffered changes and clear the corresponding change buffer bitmap bits.
- Create an empty the change buffer root page.
- Free any pages that were allocated to the change buffer.
- Reset the change buffer root page, to mark the upgrade as completed and to prevent a downgrade to an earlier version.
If an error occurs during before the final upgrade step, it should be possible to downgrade to MariaDB Server 10.8 or a later version (using the currently latest redo log format that was changed in
As noted in MDEV-11634, the change buffer may improve performance in some cases, but it is also missing a lot of potential. The main motivation for removing the change buffer in its current form is that difficult-to-reproduce corruption bugs keep popping up, such as
MDEV-24449, MDEV-26917, MDEV-30009.