"have_warnings" was set to an uninialized value when converting
a negative number to datetime.

MDEV-6099 Bad results for DATE_ADD(.., INTERVAL 2000000000000000000.0 SECOND)
MDEV-6097 Inconsistent results for CAST(int,decimal,double AS DATETIME)
MDEV-6100 No warning on CAST(9000000 AS TIME)

We have to run the derived table prepare before the unique table check to mark the derived table (in this case the unique table check can turn that table to materialized one).

use -ggdb3 if supported

  Bug #18167356: EXPLAIN W/ EXISTS(SELECT* UNION SELECT*)
                 WHERE ONE OF SELECT* IS DISTINCT FAILS.

the bugfix itself was not merged - MariaDB doesn't have this bug.

mysql_derived_merge() made correctly working with views.

Added the EXCEPTIONS-CLIENT (that was lost in the merge),
as the ascii version of http://www.mysql.com/about/legal/licensing/foss-exception/

MDEV-6281 Typo in mysql_install_db scripts
and collateral changes:

* remove mysql_tableinfo.1 and references to it (there's no mysql_tableinfo)
* for debian: create manpages for mysqlrepair, mysqlanalyze, mysqloptimize
  (as symlinks for mysqlcheck.1, just as executables are symlinks to mysqlcheck)
* remove mysqlmanager.8 and references to it
* correct "very long line" error in mysqladmin.1
* simplify and fix table formatting in mysqlbinlog.1 and mysqldump.1
* fix a typo in the help text in mysql_install_db
* aria_chk: say "for Linux on x86_64", like other tools do
  (not "for Linux at x86_64")
* add simple manpages for aria_* utilities

- Make partition pruning work for tables inside semi-join nests
  (the new condition is the same that range optimizer uses so 
   it should be ok)

- When the optimizer chose LooseScan, make_join_readinfo() should
  use the index that was chosen for LooseScan, and should not try 
  to find a better (shortest) index.

The bug was in the mysqltest.c. It didn't check the send_query result
properly, so when that fails and the thread gets disconnected,
it goes unnoticed, so the consequitive read_result call crashes.
Fixed by checking the sernd_query return.

            ! pthread_equal(pth read_self(), (&(&LOCK_open)->m_mutex)->thread)'
            fails in intern_sys_var_ptr on server shutdown after uninstalling
            TokuDB plugin at runtime

This assertion was introduced by patch for MDEV-5089 to ensure proper lock order
among LOCK_open and LOCK_global_system_variables: LOCK_open must not be held
while acquiring LOCK_global_system_variables.

intern_sys_var_ptr() may be called while freeing storage engine variables with
PLUGIN_VAR_MEMALLOC flag (when destroying table share after storage engine was
uninstalled). In this case LOCK_open is held, which is harmless because we need
global value pointer and thus won't acquire LOCK_global_system_variables.

Relaxed assertion so it is valid only for session variables.

Analysis: Can't disable the error message because you may get database
started with incorrect log file size. 

Fix: Thus only improve the error message to give more information 
to users.

Analysis: By default 10.0 creates 48M log files and 5.5 assumes they
are 5M.

Fix: Remove the error and do size comparison later.

- Fixed bug that we where using wrong checksum algorithm when using VARCHAR with fixed lenth rows
- Ensure in myisampack that HA_OPTION_NULL_FIELDS is set for tables with null fields.

mysql-test/r/myisampack.result:
  Updated results
mysql-test/t/myisampack.test:
  Added more tests
storage/myisam/mi_open.c:
  Use correct checksum algorithm when we have VARCHAR fields with fixed length records
storage/myisam/myisampack.c:
  Ensure HA_OPTION_NULL_FIELDS is set for tables with null fields.
  (This was not set by default for not compressed tables without checksums to keep MyISAM tables compatible with MySQL)

added the test case

on select from I_S.INNODB_CHANGED_PAGES

Analysis: limit_lsn_range_from_condition() incorrectly parses
start_lsn and/or end_lsn conditions.

Fix from SergeyP. Added some test cases.

All underlying tables should share the same lock type.

"Table upgrade required..."

The row format is only different for the case where we have a very old MyISAM table with varchar fields, null fields and created with CHECKSUM=1
The table is usable, except that CHECKSUM TABLE will give a wrong result and CHECK TABLE will warn about this.

I added a test for this to warn when a table needs to be upgraded, but forgot to add a test that this was only relevant for tables with CHECKSUM=1
This is now fixed.



storage/myisam/ha_myisam.cc:
  Fixed wrong test.

git://github.com/Tokutek/ft-index.git
git://github.com/Tokutek/ft-engine.git
at the tag tokudb-7.1.6