already fixed by a7ed4644.
just add a test case,

upper->item can be NULL if we're referring to an aggregate function

Item_in_subselect::pushed_cond_guards[] array is allocated only when
left_expr->maybe_null. And it is used (for row expressions) when
left_expr->element_index(i)->maybe_null.

For left_expr being a multi-column subquery, its maybe_null is
always false when the subquery doesn't use tables (see
Item_singlerow_subselect::fix_length_and_dec()
and subselect_single_select_engine::fix_length_and_dec()),
otherwise it's always true.

But row elements can be NULL regardless, so let's always allocate
pushed_cond_guards for multi-column subqueries, no matter whether
its maybe_null was forced to true or false.

MDEV-10146: Wrong result (or questionable result and behavior) with aggregate function in uncorrelated SELECT subquery

When outer reference resolved in a VIEW it still should mark aggregate function resolving border.

Found by Coverity (id 971843).
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

make_lock_and_pin didn't release the lock so we should.

Found by Coverity (id 972095).

Release the lock for the error path.

Found by Coverity (id 972093).

translog_stop_writing doesn't release a lock (though
does to a DBUG_ASSERT).

Better to just release the lock.

Found by Coverity id 972092

Found by Coverity scan - id 92087

max_data_file_size is overwritten in next statement
so this assignment didn't ever get used.

Found by Coverity (ID 1409644)

CID 971836 (#1 of 1): Same on both sides (CONSTANT_EXPRESSION_RESULT)
pointless_expression: The expression val != end && val != end does not
accomplish anything because it evaluates to either of its identical
operands, val != end.

cover ANSI_QUOTES and NO_BACKSLASH_ESCAPES in mysqltest

don't do backslash escapes inside backticks

This has been implemented in for cmake-3.6 to match distro version
of what the filename should look like.

Thanks to Domen Vranka for the suggestion.

regex didn't replace lines that were split by 16K chunk reads.

MDEV-13063 Server crashes in intern_plugin_lock or assertion `plugin_ptr->ref_count == 1' fails in plugin_init

if a forced plugin is disabled (for any reason, e.g. invalid command-line
option) - it's an error

This is actually a legacy bug:
SQL_SELECT::test_quick_select() was called
with SQL_SELECT::head not set.
It looks like that this problem can be
reproduced only on queries with ORDER BY
that use IN predicates converted to semi-joins.

This patch corrects the fix for bug mdev-7599.
When the min/max optimization of the function
opt_sum_query() optimizes away all tables of
a subquery it should not ever be rolled back.

If the optimizer chose an execution plan where
a semi-join nest were materialized and the
result of materialization was scanned to access
other tables by ref access it could build a key
over columns of the tables from the nest that
were actually inaccessible.
The patch performs a proper check whether a key
that uses columns of the tables from a materialized
semi-join nest can be employed to access outer tables.

buf_page_get_gen(): Remove the error log messages about
page flushing and eviction when
innodb_change_buffering_debug=1 is in effect.

Added forgoten method of Item_func_sp to make it correctly work with LEFT/RIGHT JOIN.
Fixed inconsistency with the null table caches.

Problem:-
This crash happens because logged stmt is quite big and while writing
Annotate_rows_log_event it throws EFBIG error  but we ignore this error
and do not call cache_data->set_incident().

Solution:-
When we normally write Binlog_log_event we check for error EFBIG, but we did
do this for Annotate_rows_log_event. We check for this error and call
cache_data->set_incident() accordingly.

# Conflicts:
#	sql/log.cc

This is another correction of the patch for bug mdev-12670.
If a derived table is merged into a select with STRAIGHT_JOIN
modifier all IN subquery predicates contained in the
specification of the derived table cannot be subject to
conversion to semi-joins.

This patch is a correction of the patch for bug mdev-12670.
With the current code handling semi-joins the following must
be taken into account.
Conversion of an IN subquery predicate into semi-join
has to be blocked if the predicate occurs:
(a) in the ON expression of an outer join
(b) in the ON expression of an inner join embedded directly
    or indirectly in the inner nest of an outer join.
The patch for mdev-12670 blocked conversion to semi-joins only
in the case (a), but not in the case (b). This patch blocks
the conversion in both cases.

When an IN subquery predicate was converted to a semi-join that were
materialized and the result of the materialization happened to be
the last in the execution plan then any conjunctive condition with RAND()
turned out to be lost.

Fixed by attaching this condition to the last top base table.

with a specially corrupted master.info one can
get an invalid heartbeat_period that will
trigger a heap overflow.

At some conditions the function opt_sum_query() can apply MIN/MAX
optimizations to to Item_sum objects of a select These optimizations
becomes invalid if this select is the subquery of an IN subquery
predicate that is converted to a EXISTS subquery. Thus in this case
the MIX/MAX optimizations that have been applied in opt_sum_query()
must be rolled back.
This bug appeared in 5.3 when the code for the cost base choice between
materialization and in-to-exists transformation of non-correlated
IN subqueries was introduced. Before this code in-to-exists
transformations were always performed before the call of opt_sum_query().

A better way of finding mysqld

The code that blocked conversion of a IN subselect pedicate to a semi-join
if it occurred in the ON expression of an outer join did not do it correctly.
As a result, the conversion was blocked for IN subselect predicates
encountered in ON expressions of INNER joins or in WHERE conditions
of mergeable views / derived tables. This patch fixes this problem.

This patch corrects the fix for the bug mdev-10693.
It is critical for the function get_best_combination() not to call
create_ref_for_key() for constant tables.
This bug could manifest itself only in multi-table subqueries where
one of the tables is accessed by a constant primary key.