Galera recovery process works in two phases. In the first
phase, mysqld is started as non-daemon with --wsrep-recover
to recover and fetch the last logged global transaction ID.
This ID is then used in second phase as the start position
(--wsrep-start-position=XX) to start mysqld as daemon.
As this process was implemented in mysqld_safe script, the
recovery did not work when server was started using systemd.
Fixed by introducing a shell script (wsrep_recovery.sh) that
mimics the first phase of the recovery process.
--defaults-xxx options must be placed before all other
options in the command line. Also moved MYSQLD_OPTS at
the end so that its options take precedence.
The collation customization code for the UCA (Unicode Collation Alrorithm)
based collations now allows to reset to and shift of characters with
implicit weights. Previously reset/shift worked only for the characters
with explicit DUCET weights. An attempt to use reset/shift with
character with implicit weights made the server crash.
The check inserts a DWARF directive to tell stack unwinding that the
bottom of the (co-routine) stack has been reached. Without this, stack
traces may attempt to continue past the bottom of the stack.
The GCC version check was incorrect, and failed to trigger for GCC
version 5.[0123].
On Windows with low precision (10-16 ms) timer used for timing queries,
the statement "set @@long_query_time=0.01" can log itself a slow if it
spawn more single timer tick.
The fix is to filter this query out from "SELECT FROM mysql.slow_log"
results
Part #2: make tree_or(tree1, tree2) to reuse tree1 for the result object
for simple cases. These include key IN (c1, ... cN).
The reuse was happening in old MySQL versions, but we stopped doing it
in the "fair choice between range and index_merge" patch.
Post-fix #2:
- Update test results
- Make the optimization conditional under @@optimizer_switch flag.
- The optimization is now disabled by default, so .result files
are changed back to be what they were before the MDEV-8989 patch.
A partial backport of 67f21fb3a077dedfd14b9ca720e926c55e682f93,
Bug#22283790: RANGE OPTIMIZER UTILIZES TOO MUCH MEMORY WITH MANY OR CONDITIONS
The backported part changes SEL_TREE::keys from being an array of
MAX_KEY elements (64*8=512 bytes) to a Mem_root_array<SEL_ARG*> (32 bytes +
alloc'ed array of as many elements as we need).
The patch doesn't fix the "not limiting memory" part, but the memory usage
is much lower with it.
Variant #4 of the fix.
Make ORDER BY optimization functions take into account multiple
equalities. This is done in several places:
- remove_const() checks whether we can sort the first table in the
join, or we need to put rows into temp.table and then sort.
- test_if_order_by_key() checks whether there are indexes that
can be used to produce the required ordering
- make_unireg_sortorder() constructs sort criteria for filesort.
When simplify_joins() converts an outer join to an inner, it should
reset the value of TABLE::dep_tables. This is needed, because the
function may have already set TABLE::dep_tables according to the outer
join dependency.
don't use MY_THREAD_SPECIFIC on the client side
in embedded:
1. server memory accounting does not track client
side memory
2. in not embedded builds, this still *might* be
useful for plugins (handlersocket, connect, etc)
