Last commit made on 2019-06-17
Get this branch:
git clone -b bb-10.1-monty

Branch merges

Branch information


Recent commits

3e9214e... by Michael Widenius <email address hidden> on 2019-06-13

Fixed Aria recovery progress printing

- When recovery failed, errors would not be printed on
  new lines.
- Print more information if file lengths are changed
- Added logging of table name for entries INCOMPLETE_LOG and

7874b2b... by Michael Widenius <email address hidden> on 2019-06-13

Give a readable error if aria_log page numbers doesn't match

MDEV-18461 Aria crash recovery failures

This does not fix the bug reported in the MDEV, but
now we get an error message of the problem instead of
an assert.

3a7c47a... by Michael Widenius <email address hidden> on 2019-06-13

Backport aria usage if LSN_FMT from 10.3

This helps when merging code between releases

65e0c9b... by Alexey Botchkov on 2019-06-14

MDEV-18661 loading the audit plugin causes performance regression.

Plugin fixed to not lock the LOCK_operations when not active.
Server fixed to lock the LOCK_plugin less - do it once per
thread and then only if a plugin was installed/uninstalled.

5b65d61... by Oleksandr Byelkin <email address hidden> on 2019-06-12

Merge branch '5.5' into 10.1

56c60b2... by Marko Mäkelä on 2019-06-12

MDEV-16111 encryption.innodb_lotoftables failed in buildbot with wrong result

Remove the test, because it easily fails with a result difference.
Analysis by Thirunarayanan Balathandayuthapani:

By default, innodb_encrypt_tables=0.
1) Test case creates 100 tables in innodb_encrypt_1.
2) creates another 100 unencrypted tables (encryption=off) in innodb_encrypt_2
3) creates another 100 encrypted tables (encryption=on) in innodb_encrypt_3
4) enabling innodb_encrypt_tables=1 and checking that only
100 encrypted tables exist. (already we have 100 in dictionary)
5) opening all tables again (no idea why)
6) After that, set innodb_encrypt_tables=0 and wait for 100 tables
to be decrypted (already we have 100 unencrypted tables)
7) dropping all databases

Sporadic failure happens because after step 4, it could encrypt the
normal table too, because innodb_encryption_threads=4.

This test was added in MDEV-9931, which was about InnoDB startup being
slow due to all .ibd files being opened. There have been a number of
later fixes to this problem. Currently the latest one is
commit cad56fbabaea7b5dab0ccfbabb98d0a9c61f3dc3, in which some tests
(in particular the test innodb.alter_kill) could fail if all InnoDB
.ibd files are read during startup. That could make this test redundant.

Let us remove the test, because it is big, slow, unreliable, and
does not seem to reliably catch the problem that all files are being
read on InnoDB startup.

efc3cb9... by sjaakola <email address hidden> on 2019-06-12

MDEV-19563 Removed references to deprecated option innodb_locks_unsafe_for_binlog

innodb_locks_unsafe_for_binlog variabe removed from wsrep_info test configuration and
recommendation to use this variable in README-wsrep was removed as well

Also relates to issue: MDEV-19544

9d886de... by Sergey Vojtovich on 2019-06-12

MDEV-16467 - MariaDB crashes because of "long semaphore wait"after migrating from 10.1 to 10.3

This patch fixes 10.2 issue reported in MDEV-16467 by partial backport of
c2118a0. Specifically "Remove not needed LOCK_thread_count from

b2f76ba... by Thirunarayanan Balathandayuthapani <email address hidden> on 2019-06-12

MDEV-16866 InnoDB fails to start upon crash recovery with "[ERROR] InnoDB: Redo log crypto: failed to decrypt log block"

- Post-push fix to change the copyright of both xtradb and innodb file.

c5fe1b8... by Thirunarayanan Balathandayuthapani <email address hidden> on 2019-06-12

MDEV-16866 InnoDB fails to start upon crash recovery with "[ERROR] InnoDB: Redo log crypto: failed to decrypt log block"

- If InnoDB encounters garbage or incomplete written log block during
recovery then don't throw the error. Treat it as end of the log.
- This kind of incomplete or empty block can be result of killing
InnoDB when writing the redo log.