manually checked every change, reverted incorrect or stupid changes.

remove unused mtr option

sql/log.h:
  Fixed compiler warnings reported for gcc 2.7.1
storage/xtradb/handler/ha_innodb.cc:
  Remove not used variables

When appliying parent combinations to the overlay,
filter them through the %skip_combinations using the overlayed filename

Post-merge fixes for mismatches that only affect 5.5 (but not 5.3)

Following reasons caused mismatches:
  - different handling of invalid values;
  - different CAST results with fractional seconds;
  - microseconds support in MariaDB;
  - different algorithm of comparing temporal values;
  - differences in error and warning texts and codes;
  - different approach to truncating datetime values to time;
  - additional collations;
  - different record order for queries without ORDER BY;
  - MySQL bug#66034.
More details in MDEV-369 comments.

make CMakeLists.txt to detect if the installed boost can be compiled with the
installed compile and specified set of compiler options.

Background: even sufficiently new Boost cannot be compiled with the sufficiently old gcc
in the presence of -fno-rtti

add missing checks to configure.cmake
remove dead code and unused HAVE_xxx constants from the sources

Don't use ER(xxx) in THD::close_connection(), when current_thd is already reset to NULL.
Prefer ER_THD() or ER_DEFAULT() instead.

      mysql_rm_table_no_locks() function was modified.
      When we construct log record for the DROP TABLE, now we
      look if there's a comment before the first table name and
      add it to the record if so.
  
per-file comments:
  sql/sql_table.cc
  MDEV-340 Save replication comments for DROP TABLE.
        comment_length() function implemented to find comments in the query,
        call it in mysql_rm_table_no_locks() and use the result to form log record.
  mysql-test/suite/binlog/r/binlog_drop_if_exists.result
  MDEV-340 Save replication comments for DROP TABLE.
        test result updated.
  mysql-test/suite/binlog/t/binlog_drop_if_exists.test
  MDEV-340 Save replication comments for DROP TABLE.
        test case added.

Add the check for sys/utsname.h to configure.cmake

use correct macro for Microsoft compiler. It is _MSC_VER , not _MSV_VER

Following reasons caused mismatches:
  - different handling of invalid values;
  - different CAST results with fractional seconds;
  - microseconds support in MariaDB;
  - different algorithm of comparing temporal values;
  - differences in error and warning texts and codes;
  - different approach to truncating datetime values to time;
  - additional collations;
  - different record order for queries without ORDER BY;
  - MySQL bug#66034.
More details in MDEV-369 comments.

- Make Item_subselect::fix_fields() ignore UNCACHEABLE_EXPLAIN flag when deciding whether 
  the subquery item should be marked as constant.

Fix : use attribute %config(noreplace)  for /etc/my.cnf , instead of (automatically generated) %config

see https://mariadb.atlassian.net/browse/MDEV-11

- index_merge/intersection is unable to work on GIS indexes, because:
  1. index scans have no Rowid-Ordered-Retrieval property
  2. When one does an index-only read over a GIS index, they do not 
     get the index tuple, because index only contains bounding box of the geometry.
     This is why key_copy() call crashed.
This patch fixes #1, which makes the problem go away. Theoretically, it would 
be nice to check #2, too, but SE API semantics is not sufficiently precise to do it.

Now partition engine adds underlying tables to the QC and ask underlying tables engine permittion to cache the query and return result of the query.

Incorrect QC cleanup in case of table registration failure fixe.

Unified interface for myisammrg & partitioned engnes for QC.

MDEV-393. Remove --loose-pbxt=OFF/loose-skip-pbxt from bootstrapper calls to avoid "unknown parameter" warning

fix incorrect merge

No commit message

No commit message

              COUNT DISTINCT GROUP BY

PROBLEM:
To calculate the final result of the count(distinct(select 1))
we call 'end_send' function instead of 'end_send_group'.
'end_send' cannot be called if we have aggregate functions
that need to be evaluated.

ANALYSIS:
While evaluating for a possible loose_index_scan option for
the query, the variable 'is_agg_distinct' is set to 'false'
as the item in the distinct clause is not a field. But, we
choose loose_index_scan by not taking this into 
consideration.
So, while setting the final 'select_function' to evaluate
the result, 'precomputed_group_by' is set to TRUE as in
this case loose_index_scan is chosen and we do not have
agg_distinct in the query (which is clearly wrong as we
have one).
As a result, 'end_send' function is chosen as the final
select_function instead of 'end_send_group'. The difference
between the two being, 'end_send_group' evaluates the
aggregates while 'end_send' does not. Hence the wrong result.

FIX:
The variable 'is_agg_distinct' always represents if 
'loose_idnex_scan' can be chosen for aggregate_distinct 
functions present in the select.
So, we check for this variable to continue with 
loose_index_scan option.


sql/opt_range.cc:
  Do not continue if is_agg_distinct is not set in case
  of agg_distinct functions.

follow-up patch for the failure on pb2 windows build

Follow up patch to resolve pb2 failure on windows platform

             primary key with innodb tables

The bug was triggered if a single ALTER TABLE statement both
added and dropped indexes and ALTER TABLE failed during drop
(e.g. because the index was needed in a foreign key constraint).
In such cases, the server index information would get out of
sync with InnoDB - the added index would be present inside
InnoDB, but not in the server. This could then lead to InnoDB
error messages and/or server crashes.

The root cause is that new indexes are added before old indexes
are dropped. This means that if ALTER TABLE fails while dropping
indexes, index changes will be reverted in the server but not
inside InnoDB.

This patch fixes the problem by dropping any added indexes
if drop fails (for ALTER TABLE statements that both adds
and drops indexes). 

However, this won't work if we added a primary key as this
key might not be possible to drop inside InnoDB. Therefore,
we resort to the copy algorithm if a primary key is added
by an ALTER TABLE statement that also drops an index.

In 5.6 this bug is more properly fixed by the handler interface
changes done in the scope of WL#5534 "Online ALTER".