MDEV-15370 Upgrade fails when both insert_undo and update_undo exist
Before MDEV-12288 in MariaDB 10.3.1, InnoDB used to partition the persistent transaction undo log into insert_undo and update_undo. MDEV-12288 repurposes the update_undo as the single undo log. In order to support an upgrade from earlier MariaDB versions, the insert_undo is recovered in data structures, called old_insert. An assertion failure occurred in TrxUndoRsegsIterator::set_next() when an incomplete transaction was recovered with both insert_undo and update_undo log. This could be easily demonstrated by starting ./mysql-test-run --manual-gdb innodb.read_only_recovery in MariaDB 10.2, and after the first kill, start up the MariaDB 10.3 server with the same parameters. The problem is that MariaDB 10.3 would roll back the recovered transaction, and finally "commit" it twice (with all changes to data rolled back), both insert_undo and update_undo with the same commit end identifier (trx->no). Our fix is to introduce a "commit number" that comprises two components: (trx->no << 1 | !old_insert). In this way, the assertion in the purge subsystem can be relaxed so that only the trx->no component must match.
Showing
Please register or sign in to comment