Conflicts:
	.bzrignore
	VERSION
	cmake/plugin.cmake
	debian/dist/Debian/control
	debian/dist/Ubuntu/control
	mysql-test/r/join_outer.result
	mysql-test/r/join_outer_jcl6.result
	mysql-test/r/null.result
	mysql-test/r/old-mode.result
	mysql-test/r/union.result
	mysql-test/t/join_outer.test
	mysql-test/t/null.test
	mysql-test/t/old-mode.test
	mysql-test/t/union.test
	packaging/rpm-oel/mysql.spec.in
	scripts/mysql_config.sh
	sql/ha_ndbcluster.cc
	sql/ha_ndbcluster_binlog.cc
	sql/ha_ndbcluster_cond.cc
	sql/item_cmpfunc.h
	sql/lock.cc
	sql/sql_select.cc
	sql/sql_show.cc
	sql/sql_update.cc
	sql/sql_yacc.yy
	storage/innobase/buf/buf0flu.cc
	storage/innobase/fil/fil0fil.cc
	storage/innobase/include/srv0srv.h
	storage/innobase/lock/lock0lock.cc
	storage/tokudb/CMakeLists.txt
	storage/xtradb/buf/buf0flu.cc
	storage/xtradb/fil/fil0fil.cc
	storage/xtradb/include/srv0srv.h
	storage/xtradb/lock/lock0lock.cc
	support-files/mysql.spec.sh

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.

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

Fix rare failures in test case rpl.rpl_gtid_basic:

 - Add another possible error code when a connection is killed.

 - Make sure that the IO thread has had time to complete its stop after START
   SLAVE UNTIL. Otherwise, START SLAVE might run before IO thread stop,
   leaving the test case with a stopped IO thread that eventually causes a
   wait timeout.

There was a race, a small window between updating slave position and updating
Seconds_Behind_Master, during which the test case could see the wrong value.

Fix by waiting for the expected status to appear.

local function variable was overwriting the global one.
also remove unused variable expansion.

control scripts (mysqld_safe for example) want to know
whether a recovery was successful or not.
total silence is too suspicious to be trusted.

MDEV-7188 main.signal_demo3 and sys_vars.max_sp_recursion_depth_func fail in biuldbot on labrador with Thread stack overrun

reduce stack requirememnts for CALL by just a little bit

Added Rows_affected to slow query log & mysql.slow_log table.

(just like in the test below)

Updated MDL_context's lock methods to accept double precision
lock_wait_timeout.

Fixed the condition to make sure mysqld process terminates when
started with wsrep-recover.

   Missing GIS functions added:
        IsRing()
        PointOnSurface
        PointOnSurface
        Relate
        Distance
        Intersection
        ConvexHull
   Other old OpenGis standard inconsistencies fixed.

MDEV-7228: innodb.innodb-page_compression_tables, innodb.innodb-page_compression_zip, innodb.innodb_stats_create_on_corrupted fail with embedded server

Problem is that tests restart the server and "shutdown_server" looks
for pid file # which is not there with embedded mode.

Fix tests so that they are not run with embedded mode.

Problem was that test tried to calculate number of pages on
buffer pool and operations done to them. This is not realible
way on buildbot.

Problem is that there is additional error message from function
that is not really needed now.

  Problem is that test could open Microsoft C++ Client Debugger
  windows with abort exceptin. Lets not try to test this on
  windows.

innodb.innodb_stats_drop_locked fail and
innodb.innodb_stats_fetch_nonexistent fails in buildbot on Windows

Analysis: Problem is that innodb_stats_create_on_corrupted
test renames mysql.innodb.index_stats and all the rest
are dependend on this table.

Fix: After rename back to original, restart mysqld to
make sure that table is correct.

Analysis: Test case uses Linux specific error codes.

Fix: Can't run test case with Windows currently because requires
to inject error to system.

        test results updated with the new GIS-related IS tables.

Analysis: If innodb_use_trim is not enabled or system does not
support fallocate to make persistent trim, we should always
write full page not only partial pages.

Fix for embedded build failure.
Also added wsrep_info plugin library to server debian package.

wsrep_info INFORMATION_SCHEMA plugin to provide WSREP_STATUS
and WSREP_MEMBERSHIP tables.

MDEV-7144 Warnings "bytes lost" during server shutdown after running connect.part_file test in buildbot

The replication relay log position was sometimes updated incorrectly at the
end of a transaction in parallel replication. This happened because the relay
log file name was taken from the current Relay_log_info (SQL driver thread),
not the correct value for the transaction in question.

The result was that if a transaction was applied while the SQL driver thread
was at least one relay log file ahead, _and_ the SQL thread was subsequently
stopped before applying any events from the most recent relay log file, then
the relay log position would be incorrect - wrong relay log file name. Thus,
when the slave was started again, usually a relay log read error would result,
or in rare cases, if the position happened to be readable, the slave might
even skip arbitrary amounts of events.

In GTID mode, the relay log position is reset when both slave threads are
restarted, so this bug would only be seen in non-GTID mode, or in GTID mode
when only the SQL thread, not the IO thread, was stopped.

Simply disallowing equality propagation into LIKE.
A more delicate fix is be possible, but it would need too many changes,
which is not desirable in 10.0 at this point.

MDEV-7037: MariaDB 10.0 does not build on Debian / kfreebsd-i386/amd64 due to MTR failure: multi_source.gtid
MDEV-7106: Sporadic test failure in multi_source.gtid
MDEV-7153: Yet another sporadic failure of multi_source.gtid in buildbot

This patch fixes three races in the multi_source.gtid test case that could
cause sporadic failures:

1. Do not put SHOW ALL SLAVES STATUS in the output, the output is not stable.

2. Ensure that slave1 has replicated as far as expected, before stopping its
connection to master1 (otherwise the following wait will time out due to rows
not replicated from master1).

3. Ensure that slave2 has replicated far enough before connecting slave1 to it
(otherwise we get an error during connect that slave1 is ahead of slave2).