maria:bb-10.1-MDEV-20247

Last commit made on 2019-08-07
Get this branch:
git clone -b bb-10.1-MDEV-20247 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.1-MDEV-20247
Repository:
lp:maria

Recent commits

47f8a18... by THIRUNARAYANAN BALATHANDAYUTHAPANI on 2019-08-07

MDEV-20247 Replication hangs with "preparing" and never starts

- The commit ab6dd774082c57f48d998e03655c06b672799b2d wrongly sets the
condition inside innobase_srv_conc_enter_innodb(). Problem is that
InnoDB makes the thread to sleep indefinitely if it is a replication
slave thread.

Thanks to Sujatha Sivakumar for contributing the replication test case.

eef7540... by Sujatha <email address hidden> on 2019-08-05

MDEV-18930: Failed CREATE OR REPLACE TEMPORARY not written into binary log makes data on master and slave diverge

Problem:
=======
Failed CREATE OR REPLACE TEMPORARY TABLE statement which dropped the table but
failed at a later stage of creation of temporary table is not written to
binarylog in row based replication. This causes the slave to diverge.

Analysis:
========
CREATE OR REPLACE statements work as shown below.

CREATE OR REPLACE TABLE table_name (a int);
is basically the same as:

DROP TABLE IF EXISTS table_name;
CREATE TABLE table_name (a int);

Hence every CREATE OR REPLACE TABLE command which dropped the table should be
written to binary log, even when following CREATE TABLE part fails. In order
to achieve this, during the execution of CREATE OR REPLACE command, when a
table is dropped 'thd->log_current_statement' flag is set. When table creation
results in an error within 'mysql_create_table' code, the error handling part
looks for this flag. If it is set the failed CREATE OR REPLACE statement is
written into the binary log inspite of error. This ensure that slave doesn't
diverge from the master. In case of row based replication the error handling
code returns very early, if the table is of type temporary. This is done based
on the assumption that temporary tables are not replicated in row based
replication.

It fails to handle the cases where a temporary table was created as part of
statement based replication at an earlier stage and the binary log format was
changed to row because of an unsafe statement. In this case when a CREATE OR
REPLACE statement is executed on this temporary table it will dropped but the
query will not be written to binary log. Hence slave diverges.

Fix:
===
In error handling code check the return status of create table operation. If
it is successful and replication mode is row based and table is of type
temporary then return. Other wise proceed further to the code which checks for
thd->log_current_statement flag and does appropriate logging.

319cec9... by Eugene on 2019-08-01

MDEV-17638 Improve error message about corruption of encrypted page

Help user distinguish between space ID and page number.

0bb8f33... by Daniel Bartholomew <email address hidden> on 2019-07-31

bump the VERSION

f79212f... by Anel Husakovic <email address hidden> on 2019-07-31

Fix extra space in mysql-test README

403e661... by Elena Stepanova on 2019-07-26

List of unstable tests for 10.1.41 release (updated)

2382cd1... by Oleksandr Byelkin <email address hidden> on 2019-07-26

Merge branch '5.5' into 10.1

f8a1a26... by Oleksandr Byelkin <email address hidden> on 2019-07-26

Move the test not suitable for embedded.

4177181... by Oleksandr Byelkin <email address hidden> on 2019-07-26

Merge branch 'merge-tokudb-5.6' into 10.1

24a0d7c... by Oleksandr Byelkin <email address hidden> on 2019-07-26

5.6.44-86.0