Last commit made on 2019-03-29
Get this branch:
git clone -b bb-10.2-compatibility

Branch merges

Branch information


Recent commits

53dac47... by Marko Mäkelä on 2019-03-29

Re-enable WITH_WSREP=ON by default

This partially reverts commit f903a4213438a1ed1b72ce55897f7332785406be.

The Debian packaging assumes that WITH_WSREP=ON is enabled.
The script debian/ is editing
debian/mariadb-server-10.2.install before it invokes cmake
via debian/rules. We would know the value of WITH_WSREP only
after invoking cmake.

Also, startup on systemd-based platforms could fail
due to the systemd scripts assuming WITH_WSREP=ON.

a31335f... by Jan Lindström on 2019-03-13

MDEV-18908: Remove galera and wsrep suites from default run suites in mtr

Idea is that many users do not install galera library and do not want
to unnecessary run galera and wsrep suites. Furthermore, failures on
these suites disturb development as buildbot shows red failing column
and causes unnecessary work for those who do not care galera tests.
There will be other way to run these suites on buildbot.

62a17e6... by varun on 2019-03-28

MDEV-18899: Server crashes in Field::set_warning_truncated_wrong_value

To fix the crash there we need to make sure that the
server while storing the statistical values in statistical tables should do it
in a multi-byte safe way.
Also there is no need to throw warnings if there is truncation while storing
values from statistical fields.

6a825cb... by Oleksandr Byelkin <email address hidden> on 2018-02-20

MDEV-13749: Server crashes in _ma_unique_hash / JOIN_CACHE::generate_full_extensions on INTERSECT

Expect index except unique constrain in case of heap table conversion.

f903a42... by Marko Mäkelä on 2019-02-04

Disable Galera (WITH_WSREP=OFF) by default

d576094... by Marko Mäkelä on 2019-02-04

Port MDEV-13333: Deadlock failure that does not occur elsewhere

Also, port the following changes:

commit d2a15092c194f47f54f8f79098747f6f1878fde4
Author: Marko Mäkelä <email address hidden>
Date: Wed Mar 14 09:39:47 2018 +0200

    lock_table_create(), lock_rec_create(): Clean up the WSREP code

    By definition, c_lock->trx->lock.wait_lock==c_lock cannot hold.
    That is, the owner transaction of a lock cannot be waiting for that
    particular lock. It must have been waiting for some other lock.
    Remove the dead code related to that. Also, test c_lock for NULLness
    only once.

commit cac373f5333ad8dcfbc2b9d512ccc589f241008e
Author: Marko Mäkelä <email address hidden>
Date: Tue Mar 13 14:15:46 2018 +0200

    Add missing #ifdef WITH_WSREP

    lock_table_create(): Move the WSREP parameter c_lock last,
    and make it NULL by default, to avoid the need for a wrapper

    lock_table_enqueue_waiting(): Move the WSREP parameter c_lock last.

e889b96... by Marko Mäkelä on 2019-01-30

Report deadlocks to the error log if log_warnings>2

To trace down the cause of a deadlock, ensure that for every
instance of reporting ER_LOCK_DEADLOCK, a message will be output
to the server error log if the log_warnings level is more than 2.

To enable the output: SET GLOBAL log_warnings=3;

60d45e0... by Sergei Golubchik on 2019-01-02

fix the test for 2019

5dd5cf3... by Marko Mäkelä on 2018-11-02

MDEV-17073 INSERT…ON DUPLICATE KEY UPDATE became more deadlock-prone

thd_rpl_stmt_based(): A new predicate to check if statement-based
replication is active. (This can also hold when replication is not
in use, but binlog is.)

que_thr_stop(), row_ins_duplicate_error_in_clust(),
row_ins_sec_index_entry_low(), row_ins(): On a duplicate key error,
only lock all index records when statement-based replication is in use.

3f1982b... by Marko Mäkelä on 2018-07-07

MDEV-16664: Change the default to innodb_lock_schedule_algorithm=fcfs

The parameter innodb_lock_schedule_algorithm was introduced in
MariaDB Server 10.1.19, 10.2.13, 10.3.4 as part of MDEV-11039.
In MariaDB 10.1, the default value of the parameter is 'fcfs',
that is, the existing algorithm is used by default. But in
later versions of MariaDB Server, the parameter was 'vats',
enabling the new algorithm.

Because the new algorithm is triggering a debug assertion failure
that suggests corruption of the transactional lock data structures,
we will revert to the old algorithm by default until we have
resolved the problem.