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

Branch merges

Branch information


Recent commits

321cbb3... by Alexander Barkov on 2019-06-03

MDEV-19675 Wrong charset is chosen when opening a pre-4.1 table

5a19908... by Alexander Barkov on 2019-05-31

MDEV-19653 Add class Sql_cmd_create_table

dd939d6... by Sergey Vojtovich on 2019-05-30

MDEV-15734 - calculation inside sizeof() warning

Reverted incorrect change introduced by 548d03d7.

As result is char**, third qsort() parameter must be sizeof(char*).
Not sizeof(result[0] + 2), which is same as sizeof(result[0]).
Not even sizeof(result[0]) + 2, which would cause invalid memory access.

Proper sorting is responsibility of logfilenamecompare() callback.

78c1be8... by Sujatha <email address hidden> on 2019-05-30

MDEV-18913: typo in error log

Following typo in error log:

2019-03-13 15:58:10 0 [Note] Reading of all Master_info entries succeded

Should be 'succeeded'

Fixed the typo with the right word 'succeeded'.

a47464d... by Sujatha <email address hidden> on 2019-05-29

MDEV-11094: Blackhole table updates on slave fail when row annotation is enabled

Post push fix.

Simplified the earlier fixes.

b347396... by Sujatha <email address hidden> on 2019-05-28

MDEV-11094: Blackhole table updates on slave fail when row annotation is enabled

rpl_blackhole.test fails when executed with following options
mysqld=--binlog_annotate_row_events=1, mysqld=--replicate_annotate_row_events=1

Test output:
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
rpl.rpl_blackhole_bug 'mix' [ pass ] 791
rpl.rpl_blackhole_bug 'row' [ fail ]
Last_Errno 1032
Last_Error Could not execute Update_rows_v1 event on table test.t1; Can't find
record in 't1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's
master log master-bin.000001, end_log_pos 1510

Enabling "replicate_annotate_row_events" on slave, Tells the slave to write
annotate rows events received from the master to its own binary log. The
received annotate events are applied after the Gtid event as shown below.
thd->query() will be set to the actual query received from the master, through
annotate event. Annotate_rows event should not be deleted after the event is
applied as the thd->query will be used to generate new Annotate_rows event
during applying the subsequent Rows events. After the last Rows event has been
applied, the saved Annotate_rows event (if any) will be deleted.

In balckhole engine all the DML operations are noops as they donot store any
data. They simply return success without doing any operation. But the existing
strictly expects thd->query() to be 'NULL' to identify that row based
replication is in use. This assumption will fail when row annotations are
enabled as the query is not 'NULL'. Hence various row based operations like
'update', 'delete', 'index lookup' will fail when row annotations are enabled.

Extend the row based replication check to include row annotations as well.
i.e Either the thd->query() is NULL or thd->query() points to query and row
annotations are in use.

8358c6f... by Marko Mäkelä on 2019-05-28

MDEV-19614: Fix innodb_plugin on Windows

LOCK_global_system_variables: Declare with MYSQL_PLUGIN_IMPORT

bf8fe32... by Marko Mäkelä on 2019-05-28

Merge 5.5 into 10.1

626f2a1... by Marko Mäkelä on 2019-05-28

MDEV-19614 SET GLOBAL innodb_ deadlock due to LOCK_global_system_variables

The update callback functions for several settable global InnoDB variables
are acquiring InnoDB latches while holding LOCK_global_system_variables.

On the other hand, some InnoDB code is invoking THDVAR() while holding
InnoDB latches. An example of this is thd_lock_wait_timeout() that is
called by lock_rec_enqueue_waiting(). In some cases, the
intern_sys_var_ptr() that is invoked by THDVAR() may acquire
LOCK_global_system_variables, via sync_dynamic_session_variables().

In lock_rec_enqueue_waiting(), we really must be holding some InnoDB
latch while invoking THDVAR(). This implies that
LOCK_global_system_variables must conceptually reside below any InnoDB
latch in the latching order. That in turns implies that the various
update callback functions must release LOCK_global_system_variables
before acquiring any InnoDB mutexes or rw-locks, and reacquire
LOCK_global_system_variables later. The validate functions are being
invoked while not holding LOCK_global_system_variables and thus they
do not need any changes.

The following statements are affected by this:

SET GLOBAL innodb_adaptive_hash_index = …;
SET GLOBAL innodb_cmp_per_index_enabled = 1;
SET GLOBAL innodb_old_blocks_pct = …;
SET GLOBAL innodb_fil_make_page_dirty_debug = …; -- debug builds only
SET GLOBAL innodb_buffer_pool_evict = uncompressed; -- debug builds only
SET GLOBAL innodb_purge_run_now = 1; -- debug builds only
SET GLOBAL innodb_purge_stop_now = 1; -- debug builds only
SET GLOBAL innodb_log_checkpoint_now = 1; -- debug builds only
SET GLOBAL innodb_buf_flush_list_now = 1; -- debug builds only
SET GLOBAL innodb_buffer_pool_dump_now = 1;
SET GLOBAL innodb_buffer_pool_load_now = 1;
SET GLOBAL innodb_buffer_pool_load_abort = 1;
SET GLOBAL innodb_status_output = …;
SET GLOBAL innodb_status_output_locks = …;
SET GLOBAL innodb_encryption_threads = …;
SET GLOBAL innodb_encryption_rotate_key_age = …;
SET GLOBAL innodb_encryption_rotation_iops = …;
SET GLOBAL innodb_encrypt_tables = …;
SET GLOBAL innodb_disallow_writes = …;

buf_LRU_old_ratio_update(): Correct the return type.

242a28c... by Marko Mäkelä on 2019-05-28

MDEV-6812: Remove the wrapper my_log2f()