Fixed a crash during automatic zerofill of moved Aria table
This could happen if one did a DML with a moved table that one had done
an external zerofill on.
The crash happend because a message that was supposed to be sent to
a repair report was instead sent to the result, which caused an ASSERT
MDEV-30114 Incremental prepare fails when innodb_undo_tablespaces > 0
- Mariabackup fails to open the undo tablespaces while applying delta
files to the corresponding data file. Mariabackup opens the
undo tablespaces first time in srv_undo_tablespaces_init() and does
tries to open the undo tablespaces in xtrabackup_apply_deltas() with
conflicting mode and leads to the failure.
- Mariabackup should close the undo tablespaces before applying
the incremental delta files.
Some builders in our CI, most notably FreeBSD and IBM AIX, do not support
sparse files. Also, Microsoft Windows requires special means for creating
sparse files. Since these platforms do not run ./mtr --big-test, we will
for now simply move the test to a separate file that requires that option.
MDEV-29512 deadlock between commit monitor and THD::LOCK_thd_data mutex
This commit contains only a mtr test for reproducing the issue in MDEV-29512
The actual fix will be pushed in wsrep-lib repository
The hanging in MDEV-29512 happens when binlog purging is attempted, and there is
one local BF aborted transaction waiting for commit monitor.
The test will launch two node cluster and enable binlogging with expire log days,
to force binlog purging to happen.
A local transaction is executed so that will become BF abort victim, and has advanced
to replication stage waiting for commit monitor for final cleanup (to mark position in innodb)
after that, applier is released to complete the BF abort and due to binlog configuration,
starting the binlog purging. This is where the hanging would occur, if code is buggy
Reviewed-by: Jan Lindström <email address hidden>
283efe2...
by
Daniele Sciascia <email address hidden>
MDEV-29878 Galera test failure on MDEV-26575
Test MDEV-26575 fails when it runs after MDEV-25389. This is because
the latter simulates a failure while an applier thread is
created in `start_wsrep_THD()`. The failure was not handled correctly
and would not cleanup the created THD from the global
`server_threads`. A subsequent shutdown would hang and eventually fail
trying to close this THD.
Reviewed-by: Jan Lindström <email address hidden>
97d9bf9...
by
Daniele Sciascia <email address hidden>
Restore auto increment offset in test galera_join_with_cc_A
