.. logged under row binlog format
In the early stages of ALTER TABLE execution, the implementation
checks whether its a NOOP (alter_info->flags == 0), and if so,
it returns after logging the command to binary log. The logging,
however, was done unconditionally.
Fixed by skipping the logging for temporary tables when under row
based replication.
.. share->last_version' failed in myisam/mi_open.c:67: test_if_reopen
During the RENAME operation since the renamed temporary table is also
opened and added to myisam_open_list/maria_open_list, resetting the
last_version at the end of operation (HA_EXTRA_PREPARE_FOR_RENAME)
will cause an assertion failure when a subsequent query tries to open
an additional temporary table instance and thus attempts to reuse it
from the open table list.
This commit fixes the issue by skipping flush/close operations executed
toward the end of ALTER for temporary tables. It also enables a shortcut
for simple ALTERs (like rename, disable/enable keys) on temporary
tables.
As safety checks, added some assertions at code points that should not
be hit for temporary tables.
- Tabular EXPLAIN now prints "RECURSIVE UNION".
- There is a basic implementation of EXPLAIN FORMAT=JSON.
- it produces "recursive_union" JSON struct
- No other details or ANALYZE support, yet.
We assume all around the code that null_value==true is in sync
with NULL value returned by val_str()/val_decimal().
Item_sum_sum::val_decimal() erroneously returned a non-NULL value together
with null_value set to true. Fixing to return NULL instead.
explain for the query containing WITH clause
with an unreferenced CTE caused a crash.
Added a test covered this case.
Also added a test for usage CTE in different parts of union.
Shared variables of Delayed_insert may be updated without mutex protection
when delayed insert thread gets an error.
Re-acquire mutex earlier, so that shared variables are protected.
The memory alloc-ed initially for wsrep_sst_auth to store the
value specified in config was lost as the global variable was
reset while in process of masking it and thus, could never be
reclaimed on shutdown.
The patch for bug mdev-9937 actually did not fix the problem
of name resolution for tables used in views referred in queries
with WITH clauses. This fix corrects the patch.
The problem was caused by a merged semi-join, which contained a non-merged
semi-join, which used references to the top-level query in the left_expr.
When moving non-merged semi-join from the subquery to its parent, do not
forget to call fix_after_pullout for its Item_subselect. We need to do
that specifically, because non-merged semi-joins do not have their
IN-equality in the WHERE clause at this stage.
Temporary tables created for recursive CTE
were instantiated at the prepare phase. As
a result these temporary tables missed
indexes for look-ups and optimizer could not
use them.
Fix get_quick_keys(): When building range tree from a condition
in form
keypart1=const AND (keypart2 < 0 OR keypart2>=0)
the SEL_ARG for keypart2 represents an interval (-inf, +inf).
However, the logic that sets UNIQUE_RANGE flag fails to recognize
this, and sets UNIQUE_RANGE flag if (keypart1, keypart2) covered
a unique key.
As a result, range access executor assumes the interval can have
at most one row and only reads the first row from it.
Transaction replay causes the THD to re-apply the replication
events from execution, using the same path appliers do. While
applying the log events, the THD's timestamp is set to the
timestamp of the event.
Setting the timestamp explicitly causes function NOW() to
always the timestamp that was set. To avoid this behavior we
reset the timestamp after replaying is done.
This changes variable wsrep_max_ws_size so that its value
is linked to the value of provider option repl.max_ws_size.
That is, changing the value of variable wsrep_max_ws_size
will change the value of provider option repl.max_ws_size,
and viceversa.
The writeset size limit is always enforced in the provider,
regardless of which option is used.
This patch includes two fixes:
1) Rollback when wsrep_max_ws_rows is exceeded would not switch
back to previous autocommit mode; and 2) Internal rows counter
would not be reset on implicit commits.
Make the slave SQL thread always output to the error log the message "Slave
SQL thread exiting, replication stopped in ..." whenever it previously
outputted "Slave SQL thread initialized, starting replication ...".
Before this patch, it was somewhat inconsistent in which cases the message
would be output and in which not, depending on the exact time and cause of
the condition that caused the SQL thread to stop.
TABLE_SHARE::init_from_binary_frm_image has a rule: if an index
has a partially-covered column (like in "KEY(col(N))" ), then dont
provide "Extended Keys" feature for this index.
The problem was that due to coding error Extended Keys feature was
disabled for *ALL* subsequent indexes. Fixed the error.
The problem was introduced by 1859caf60b:
MDEV-10175: range optimizer calls records_in_range() for full extended keys
Make the range optimizer not call records_in_range() when it would
not give any benefit.
that patch used an incorrect way to check for full extended key. Now fixing
the check.
Addreses are not necessarily between heap_start && heap_end. Malloc
calls using mmap can place pointers outside these bounds. In this case,
we'll warn the user that the query pointer is potentially invalid.
However, we'll attempt to print the data anyway after we're done
printing everything else.
The crash was caused by this problem:
get_best_group_min_max() tries to construct query plans for keys that
are not processed by the range optimizer. This wasn't a problem as long
as SEL_TREE::keys was an array of MAX_KEY elements.
However, now it is a Mem_root_array and only has elements for the used
keys, and get_best_group_min_max attempts to address beyond the end of
the array.
The obvious way to fix the crash was to port (and improve) a part of
96fcfcbd7b5120e8f64fd45985001eca8d36fbfb from mysql-5.7. This makes
get_best_group_min_max not to consider indexes that Mem_root_arrays
have no element for.
After that, I got non-sensical query plans (see MDEV-10325 for details).
Fixed that by making get_best_group_min_max to check if the index is in
table->keys_in_use_for_group_by bitmap.
