This fixes
MDEV-9538 Server crashes in check_show_access on SHOW STATISTICS
MDEV-9539 Server crashes in make_columns_old_format on SHOW GEOMETRY_COLUMNS
MDEV-9540 SHOW SPATIAL_REF_SYS and SHOW SYSTEM_VARIABLES return empty results with numerous warnings
when doing set_field_to_new_field (from switch_to_nullable_trigger_fields())
make sure that the field we're about to change actually belongs
to the right table (otherwise we cannot dereference new_field[]
array as the wrong table might have more fields than
new_field[] has elements)
Case: table with a NOT NULL field, BEFORE UPDATE trigger,
and UPDATE with a subquery that uses GROUP BY on that
NOT NULL field, and needs a temporary table for it.
Because of the BEFORE trigger, the field becomes nullable
temporarily. But its Item_field (used in GROUP BY) doesn't.
When working with the temptable some code looked at
item->maybe_null, some - at field->null_ptr.
The fix: make Item_field nullable when its field is.
This triggers an assert. The group key size is calculated
before the item is made nullable, so the group key doesn't
have a null byte. The fix: make fields/items nullable
before the group key size is calculated.
when replicating old temporal type fields (that don't store
metadata in the binlog), take the precision from
destination fields.
(this fixes the replication failure, crashes were
fixed in a different commit)
* make a local variable for target_table->field[col]
* move an often-used bit function to my_bit.h
* remove a non-static and not really needed trivial comparison
function with a very generic name
configured withtout username
Federated/spider/connect engines or replication threads connecting to other host
with empty user name may crash mysqld.
This is addition to original patch, which adds a test case and amends a macro.
fix a few cases where a successful ALTER was not binlogged:
* on errors after the completed ALTER, binlog it, then return an error
* don't let thd->killed abort open_table() after completed
online ALTER.
1. unused static inline functions are only removed at -xO4,
otherwise test binaries will depend on various mysys
symbols that they don't use. Link test with libmysys.
2. Sphinx - don't instantiate (explicitly) templates before
they're defined. Or, rather, don't instantiate them explicitly at
all.
3. GIS - don't use anonymous unions and structs.
Problem was that created table was not marked as used (not set query_id) and so opening tables for stored function pick it up (as opened place holder for it) and used changing TABLE internals.
The select mentioned in the bug attempted to create a temporary table
using the maria storage engine. The table needs to have primary keys such that
duplicates can be removed. Unfortunately this use case has a longer
than allowed key and the tmp table got created without a temporary key.
We must not allow materialization for the subquery if the total key
length and key parts is greater than what the storage engine supports.
When one evaluates row-based comparison like (X, Y) = (A,B), one should
first call bring_value() for the Item that returns row value. If you
don't do that and just attempt to read values of X and Y, you get stale
values.
Semi-join/Materialization can take a row-based comparison apart and
make ref access from it. In that case, we need to call bring_value()
to get the index lookup components.
Consider a query with subquery in form t.key=(select ...). Suppose, the
parent query uses this equality for ref access.
It will attempt to evaluate the subquery in get_best_combination(),
right before the join->join_tab[...] array is filled. The problem was
that subquery optimization will attempt to look at parent's join->join_tab
to check how many times subquery will be executed (and crash).
Fixed by not doing that when the subquery is constant (non-constant
subqueries are only be evaluated during join execution, so they are not
affected)
Revert the patch for MDEV-9504.
It causes test failures, attempt to fix these causes more failures. The
source of all this is that the code in test_if_skip_sort_order() has
a peculiar way of treating select_limit parameter:
Correct value is computed when the query plan is changed. In other cases,
we use an approximation that ignores the presence of GROUP BY clause,
or JOINs, or both.
A patch that fixes all of the above would be too big to do in 10.1
create_partition_index_description() had wrong logic to calculate
length of the key value buffer that is used by the range optimizer.
For some reason it used MAX(partitioning_columns_len,
subpartitioning_columns_len) while it should use SUM of these values.
- Legacy code would set JOIN_TAB::limit only for EXPLAIN queries (this
variable is only used when producing EXPLAIN output)
- ANALYZE/SHOW EXPLAIN need to produce EXPLAIN output for non-EXPLAIN
queries, too, so we should always set JOIN_TAB::limit.
DBUG_ASSERT() added in the patch for MDEV-9181 did not take into account
special circumstances for the prepared statement EXECUTE. Fixig the assert.
Also, extending and fixing comments made during MDEV-9181.
