mysql-test/suite/maria/insert_select.result:
  Added test case
mysql-test/suite/maria/insert_select.test:
  Added test case
mysys/thr_lock.c:
  Ensure we don't allow concurrent_insert when a read_no_write lock is in use

Stage "Filling schema table" is now properly shown in 'show processlist'


mysys/mf_keycache.c:
  Simple cleanup with more comments
sql/lock.cc:
  Return to original stage after mysql_lock_tables
  Made 'Table lock' as a true stage
sql/sql_show.cc:
  Restore original stage after get_schema_tables_result

- The code that tested if
     WHERE expr=value AND expr=const
  can be rewritten to:
     WHERE const=value AND expr=const
  was incomplete in case of STRING_RESULT.
- Moving the test into a new function, to reduce duplicate code.

FULLTEXT indexes do not permit index first lookups. By calling:
ha_index_first() with a garbage parameter, random data gets overwritten
that causes the table->field array to be corrupted. Subsequently, when
the field array is accessed, a segfault occurs.

By not allowing index statistics for FULLTEXT indexes, the problem is
resolved.

Fixing a wrong assymetric code in Arg_comparator::set_cmp_func().
It existed for a long time, but showed up in 10.0.14 after the fix
for "MDEV-6666 Malformed result for CONCAT(utf8_column, binary_string)".

MDEV-7254 Assigned expression is evaluated twice when updating column TIMESTAMP NOT NULL
The test type_timestamp failed depending on the build machine time zone.
Setting a fixed time zone for the test.

column TIMESTAMP NOT NULL
      
Analysis: Problem was that value->is_null() function is called
even when user had explicitly set the value for timestamp
field. Calling this function had the side effect that
expression was evaluated twice.
      
Fix: (by Sergei Golubchik) check instead value->null_value.

	innodb_bug12400341
	innodb-mdev7046
	innodb_stats_fetch_nonexistent

  
Structure of the table created by the test to archive mysql.slow_log
data didn't match the structure of mysql.slow_log. The failure only 
appeared if the slow_log was not empty, which was very rare. 
  
Updated the structure of the table. 

The problem was a too low timeout for slave reconnect. It was set to 9 seconds
(10 retries with 1 second in-between). This is occasinally too short on some
Buildbot hosts, when the test crashes and restarts the master while the slave
IO thread is running.

Fix by increasing --master-retry-count for this test.

            mysql.service failed to load

Added 'systemctl daemon-reload' command in postin and
postun rpm scripts.

The test case injects a DBUG that will crash the server during replication,
then does a START SLAVE. We need to use --error 0,2006,2013 on the START
SLAVE, so that we will not fail the test if the server has time to crash
before the START SLAVE returns to the client.

Fixes a failure seen in Buildbot.

Test causes OS error printout and we need to supress this
error message on tests. Additionally, test could cause
different error codes on different OSs.

The bug occurs when a transaction does a retry after all transactions have
done mark_start_commit() in a batch of group commit from the master. In this
case, the retrying transaction can unmark_start_commit() after the following
batch has already started running and de-allocated the GCO. Then after retry,
the transaction will re-do mark_start_commit() on a de-allocated GCO, and also
wakeup of later GCOs can be lost.

This was seen "in the wild" by a user, even though it is not known exactly
what circumstances can lead to retry of one transaction after all transactions
in a group have reached the commit phase.

The lifetime around GCO was somewhat clunky anyway. With this patch, a GCO
lives until rpl_parallel_entry::last_committed_sub_id has reached the last
transaction in the GCO. This guarantees that the GCO will still be alive when
a transaction does mark_start_commit(). Also, we now loop over the list of
active GCOs for wakeup, to ensure we do not lose a wakeup even in the
problematic case.

Analysis: For some reason actual thread handle is not
returned on Windows instead lpThreadId was returned and
thread handle was closed after thread create. Later
CloseHandle was called for recv_writer_thread_handle
and psort_info->thread_hdl.

Fix: Return thread handle from os_thread_create()
also on Windows and store these thread handles also
in srv0start.cc so that they can be later closed.

Use include/sync_with_master_gtid.inc instead of --sync_with_master to avoid a
race in the test case.

In parallel replication, the old-style slave position (which is used by
--sync_with_master) is updated out-of-order between parallel threads. This
makes it possible for the position to be updated past DROP TEMPORARY TABLE t2
just before the commit of INSERT INTO t1 SELECT * FROM t2 becomes visible.

In this case, there is a small window where a SELECT just after
--sync_with_master may not see the changes from the INSERT.

The bug was fixed by Serg earlier by including Sphinx 2.2.6, but he forgot to update the test case.

Patch by James Taylor.

scripts/mysql_system_tables.sql:
  Removed DEFAULT from a blob definition as this can cause problems.

Fix a possible race in the test case when restarting the server.

Make sure we have disconnected before waiting for the reconnect
that signals that the server is back up. Otherwise, we may in
rare cases continue the test while the old server is shutting
down, eventually leading to "connection lost" failure.

Updated hardcoded event numbers according to current GTID logic

RENAME TABLE on a non-existing table produces a better error message

  
Updated engines/* test results according to the bugfix MDEV-5894
(MySQL BUG#34750: Print database name in Unknown Table error message)

Error message was changed along with CREATE OR REPLACE TABLE fixes

Result files updated according to bugfix for MySQL#55843 (Handled 
condition appears as not handled)

In 10.0 output of SHOW DATABASES appears to be sorted, while in result
files it is not. 
Added sorted_result for certainty and updated result files.

otherwise mysqltest complains "No queries executed but non-empty result file found!"

in particular, not fail with --vertical_results

There was a race. The test case was expecting the slave to start processing a
particular DELETE statement, then the test would stop the slave at this
point. But there was missing something to wait until the slave would actually
reach this point; thus depending on timing it was possible that the slave
would be stopped too early, causing .result file difference.

Fixed by adding an appropriate wait to the test case.

Problem with test is that test causes OS failures that change. 
Idea with test is just to test that server does not crash, no other
output is necessary.

The problem was a race between the debug code in the server and the SHOW
EXPLAIN FOR in the test case.

The test case would wait for a query to reach the first point of interest
(inside dbug_serve_apcs()), then send it a SHOW EXPLAIN FOR, then wait for the
query to reach the next point of interest. However, the second wait was
insufficient. It was possible for the the second wait to complete immediately,
causing both the first and the second SHOW EXPLAIN FOR to hit the same
invocation of dbug_server_apcs(). Then a later invocation would miss its
intended SHOW EXPLAIN FOR and hang, and the test case would eventually time
out.

Fix is to make sure that the second wait can not trigger during the first
invocation of dbug_server_apcs(). We do this by clearing the thd_proc_info
(that the wait is looking for) before processing the SHOW EXPLAIN FOR; this
way the second wait can not start until the thd_proc_info from the first
invocation has been cleared.

Fix wording in error log message, to be consistent with other messages ("IO thread" -> "I/O thread").