The function ibuf_remove_free_page() may be called while the caller
is holding several mutexes or rw-locks. Because of this, this
housekeeping loop may cause performance glitches for operations that
involve tables that are stored in the InnoDB system tablespace.
Also deadlocks might be possible.

The worst impact of all is that due to the mutexes being held, calls to
log_free_check() had to be skipped during this housekeeping.
This means that the cyclic InnoDB redo log may be overwritten.
If the system crashes during this, it would be unable to recover.

The entry point to the problematic code is ibuf_free_excess_pages().
It would make sense to call it before acquiring any mutexes or rw-locks,
in any 'pessimistic' operation that involves the system tablespace.

fseg_create_general(), fseg_alloc_free_page_general(): Do not call
ibuf_free_excess_pages() while potentially holding some latches.

ibuf_remove_free_page(): Do call log_free_check(), like every operation
that is about to generate redo log should do.

ibuf_free_excess_pages(): Remove some assertions that are replaced
by stricter assertions in the log_free_check() that is now called by
ibuf_remove_free_page().

row_ins_sec_index_entry(), row_undo_ins_remove_sec_low(),
row_undo_mod_del_mark_or_remove_sec_low(),
row_undo_mod_del_unmark_sec_and_undo_update(): Call
ibuf_free_excess_pages() if the operation may involve allocating pages
and change buffering in the system tablespace.

Its output is useless,and, in case of large output, it also may prevent
with search_pattern_in_file.inc from working.

This is a genuine error, and will crash debug buildd in runtime checks if not fixed.
it is better to fail during compile.

The workaround, an extra cmake calls, somehow makes the
connect/cmake_install.cmake to lose installation of connect-engine's
specific jar files.

When MySQL 5.0.3 introduced InnoDB support for two-phase commit,
it also introduced the questionable logic to roll back XA PREPARE
transactions on startup when innodb_force_recovery is 1 or 2.

Remove this logic in order to avoid unwanted side effects when
innodb_force_recovery is being set for other reasons. That is,
XA PREPARE transactions will always remain in that state until
InnoDB receives an explicit XA ROLLBACK or XA COMMIT request
from the upper layer.

At the time the logic was introduced in MySQL 5.0.3, there already
was a startup parameter that is the preferred way of achieving
the behaviour: --tc-heuristic-recover=ROLLBACK.

Problem was that if column was created in alter table when
it was refered again it was not tried to find from list
of current columns.

mysql_prepare_alter_table:
  There is two cases
    (1) If alter table adds a new column and then later alter
        changes the field definition, there was no check from
	list of new columns, instead an incorrect error was given.
    (2) If alter table adds a new column and then later alter
        changes the default, there was no check from list of
	new columns, instead an incorrect error was given.

also fix innodb

Revert the following change, because Memcached is not present
in MariaDB Server. We had better avoid adding dead code.

commit d9bc5e03d788b958ce8c76e157239953db60adb2
Author: Aakanksha Verma <aakanksha.verma@oracle.com>
Date:   Thu May 18 14:31:01 2017 +0530

    Bug #24605783 MYSQL GOT SIGNAL 6 ASSERTION FAILURE

Includes Percona XtraDB and TokuDB 5.6.36-82.1

We need to pull rpl config files from MySQL before these tests can be
run.

Problem was a memory overflow in MRR

Reviewed by Sergei Petruna. Testcase by Elena

Squash all connect/10.0's commits into one and keep only
changes from storage/connect directory.

Fix storage_engine test results

MDEV-9739 Assertion `m_status == DA_ERROR || m_status == DA_OK' failed in Diagnostics_area::message() ; connect.xml* tests fail in buildbot

remove ~15 years old print_lock_error() function, use
handler::print_error() instead

Backport from 10.1

        Test fixed for IA64.

        Calculation of the polygon's centroid fixed.

Following merge from 5.6.36, this merge also rejects changes that
collided with the rejection of 6ca4f693c1ce472e2b1bf7392607c2d1124b4293.

We initially rejected 6ca4f693c1ce472e2b1bf7392607c2d1124b4293 because
it was introducing a new storage engine API method.

One query was removed due to inconsistent behaviour with subquery cache
enabled vs disabled. MDEV-13399 has been created to track this change
and fix.