ha_partition::init_record_priority_queue()
Cherry-pick rev.6b0ee0c795499cee7f9deb649fb010801e0be4c2 from mysql-5.6.
Bug #18305270 BACKPORT BUG#18694052 FIX
FOR ASSERTION `!M_ORDERED_REC_BUFFER'
FAILED TO 5.6
PROBLEM
-------
Missed to remove record priority queue if
init_index failed for a partition which
was causing the crash.
FIX
---
Remove priority queue if init_index fails
for partition.
Assertion `inited==INDEX' failed in int handler::ha_index_first(uchar*)
The crash was because errors from init_read_record_idx() was not taken care of.
new features:
set event_scheduler=ON|OFF will now try to init event scheduler
if it's not enabled
set event_scheduler=default will try to enable it based on
the value of the event_scheduler when mysqld was started
When CHANGE MASTER was executed as a PS, its attributes were wrongly
getting reset toward the end of PREPARE. As a result, the subsequent
executions had no effect. Fixed by making sure that the CHANGE MASTER
attributes are preserved during the lifetime of the PS.
Just "Master" could be understood as the master IP or hostname and thus can
cause confusion to db admins. "Master connection name" clearly states that
the log line contains connection name in the (possibly) multi-master setup.
MDEV-8685 MariaDB fails to decode Anonymous_GTID entries
MDEV-5705 Replication testing: 5.6->10.0
- Ignoring GTID events from MySQL 5.6+ (Allows replication from MySQL 5.6+ with GTID enabled)
- Added ignorable events from MySQL 5.6
- mysqlbinlog now writes information about GTID and ignorable events.
- Added more information in error message when replication stops because of wrong information in binary log.
- Fixed wrong test when write_on_release() should flush cache.
(even when configured with --binlog-format=statement).
Before we got an error on the slave and the slave stopped if the master
was configured with --binlog-format=mixed or --binlog-format=row.
When we calculate max_key_len for RANGE_OPT_PARAM::min_key/max_key, take
into account that QUICK_RANGE::QUICK_RANGE for some reason assumes
that there is one more byte there:
max_key((uchar*) sql_memdup(max_key_arg,max_length_arg+1)),
EXPLAIN INSERT ... SELECT tried to use SELECT's execution path. This
caused a collection of problems:
- SELECT_DESCRIBE flag was not put into select_lex->options, which
means it was not in JOIN::select_options either (except for the first
member of the UNION).
- This caused UNION members to be executed. They would attempt to write
join output rows to the output.
- (Actual cause of the crash) second join sibling would call
result->send_eof() when finished execution. Then,
Explain_query::print_explain would attempt to write to query output
again, and cause an assertion due to non-empty query output.
Problem was in rewriting left expression which had 2 references on it. Solved with making subselect reference main.
Item_in_optimized can have not Item_in_subselect reference in left part so type casting with no check is dangerous.
Item::cols() should be checked after Item::fix_fields().
[EXPLAIN] INSERT .. SELECT creates a select_insert object.
select_insert calls handler->start_bulk_insert() during
initialization.
For MyISAM/Aria this requires that a matching call to
handler->end_bulk_insert() call is made.
Regular INSERT .. SELECT accomplishes this by calling either
select_result->send_eof() or select_result->abort_result_set().
EXPLAIN INSERT ... SELECT didn't call either, which resulted in
improper de-initializaiton of handler object. Make it call
abort_result_set(), which invokes handler->end_bulk_insert().
Addendum:
* Before calling THD::init_for_queries(), flip the current_thd to wsrep
thread so that memory gets allocated for the right THD.
* Use wsrep_creating_startup_threads instead of plugins_are_initialized
as the condition for the execution of THD::init_for_queries() within
start_wsrep_THD(), as use of latter could still leave some room for
race.
The crash was caused by range optimizer using RANGE_OPT_PARAM::min_key
(and max_key) to store keys. Buffer size was a good upper bound for
range analysis and partition pruning, but not for EITS selectivity
calculations.
Fixed by making these buffers variable-size. The sizes are calculated
from [pseudo]indexes used for range analysis.
Problem:
When mysqld starts as a galera node, it creates 2 system threads
(applier & rollbacker) using start_wsrep_THD(). These threads are
created before plugin initialization (plugin_init()) for SST methods
like rsync and xtrabackup.
The threads' initialization itself can proceed in parallel to mysqld's
main thread of execution. As a result, the thread initialization code
(start_wsrep_THD()) can end up accessing some un/partially initialized
structures (like maria_hton, in this particular case) resulting in
segfault.
Solution:
Fixed by calling THD::init_for_queries() (which accesses maria_hton)
only after the plugins have been initialized.
The code was using the wrong variable when comparing the binlog name
for the UNTIL position. This could cause the comparison to fail after
binlog rotation, in turn causing the UNTIL clause to not trigger slave
stop.
Before this, FLUSH TABLES and FLUSH TABLES t1 (REFRESH_TABLES hereafter) were executed locally,
which also had implications for GTID. MySQL async replication does
replicate FLUSH TABLES.
Hence, this commit
a) Adds REFRESH_TABLES to TOI.
b) Skips LOCK-based REFRESH_TABLES from TOI, ie. FLUSH TABLES WITH READ
LOCK and FLUSH TABLES FOR EXPORT.
c) Executes them after reload_acl_and_cache. This is done since
reload_acl_and_cache checks for thd->locked_tables_mode and does upgrade
of MDL locks accordingly. A failure here means REFRESH_TABLES cannot
run.
i) This is also important since LOCK TABLES is not replicated in
galera.
d) Test galera_flush has been modified for
i) wsrep_replicate_myisam SESSION variable.
ii) Testing REFRESH_TABLES.
iii) Testing REFRESH_TABLES + LOCK TABLES.
e) Use different WSREP_TO_ISOLATION_BEGIN for global FLUSH TABLES and FLUSH TABLES <table,>.
