THD::thd->activate_stmt_arena_if_needed() should be used to temporary activating statement arena instead of direct usage of THD::set_n_backup_active_arena() because possible such scenario:
  1) func1 saves current arena and activates copy1 of statement arena
  2) func2 saves copy1 of statement arena setup by func1 and activates copy2
  3) some changes made for copy 2
  4) func2 stores changed copy2 back to statenet arena and activates copy1
  5) func1 store unchanged copy1 back to statemnt arena (rewrite changed copy 2 so changes become lost) and activates arena which was before.

Fix ha_myisammrg::update_create_info() to do what ha_myisammrg::append_create_info() does -
take sub-table names from TABLE_LIST, not reverse engineer tablefile names.

Backport praveenkumar.hulakund@oracle.com-20120127081643-u7dxy23i8yyqarm7 from mysql-5.6

mysql_tzinfo_to_sql is not compiled under Windows in the pre-5.5 versions.
Do not set the MYSQL_TZINFO_TO_SQL variable in the version prior to 5.5
under Windows.

Allow only one level of symlink recursion in mysql_tzdata_to_sql,
to avoid infinite loops.

The loop in the binary search in remove_status_vars() was
incorrectly implemented and could continue infinitely in some cases.
Rewrote the binary search code.

This a an old legacy performance bug.
When a very selective range scan existed for the second table in a join,
and, at the same time, there was another range condition depending on the
fields of the first table, the optimizer chose a plan with
'Range checked for each record'. This plan was extremely inefficient in
comparison with the regular selective range scan.
As a matter of fact the range scan chosen for each record was the same as
that selective range scan. 

Changed the test case for bug 24776 to preserve the old output for explain.
 

   not_enough_points() introduced to check if the spatial object is incorrect.

extend 5.1 client library to read 4 byte capabilities from the first handshake packet.
two higher bytes are always zeros for 5.1 servers.

MDEV-4280: Assertion `empty_size == empty_size_on_page' failure in ma_blockrec.c or ER_NOT_KEYFILE on query with DISTINCT and GROUP BY
This could happen when using Aria for internal temporary files (default case) and using DISTINCT.
_ma_scan_restore_block_record() didn't work correctly if there was rows inserted, updated or deleted on the handler
between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record().
The effect was that some DISTINCT queries that used remove_dup_with_compare() could fail.

.bzrignore:
  Ignore sql_yacc.hh
mysql-test/suite/maria/r/distinct.result:
  Test case for MDEV-4280
mysql-test/suite/maria/t/distinct.test:
  Test case for MDEV-4280
mysql-test/t/mysql.test:
  Fixed test suite (we could get error -1 in some cases)
sql/sql_select.cc:
  Break loop if restart_rnd_next() gives an error
storage/maria/ha_maria.cc:
  scan_restore_pos() can return disk fault error.
storage/maria/ma_blockrec.c:
  _ma_scan_remember_block_record() did incorrectly update scan.dir instead of scan_save.dir .
  _ma_scan_restore_block_record() didn't work correctly if there was rows inserted,updated or deleted on the handler
  between calls to _ma_scan_remember_block_record() and _ma_scan_restore_block_record().
  Fixed by adding counters for row changes and reading the current scan page if changes had been made.
storage/maria/ma_blockrec.h:
  scan_restore_pos() can return disk fault error.
storage/maria/ma_delete.c:
  Increment row_changes
storage/maria/ma_scan.c:
  scan_restore_pos() can return disk fault error.
storage/maria/ma_update.c:
  Increment row_changes
storage/maria/ma_write.c:
  Increment row_changes
storage/maria/maria_def.h:
  scan_restore_pos() can return disk fault error.

Removed "optimization" which caused preoblems on second execution of PS with string parameter in LIMIT clause.

Fixed test_bug43560 to be able to skipp it if connection is UNIX socket.

fixes for gcc 4.8 - compilation warnings and -fsanitize=address

update 5.1 to replicate from 10.0 and
to show the server version (as of 10.0) correctly

sql-common/client.c:
  mdev:4088
sql/slave.cc:
  use the version number, not just the first character of the version string
  (we want 10 > 4 not "10" < "4").

./mtr --suite=main,plugins
will work on all branches.

        Need to check if the number of points is 0 for the polygon.

        Forgotten DBUG_ASSERT should be replaced with the 'return error'.

Item_default_value inherited form Item_field so should create temporary table field similary.

    Additional fixes for possible overflows in length-related
    calculations in 'spatial' implementations.
    Checks added to the ::get_data_size() methods.
    max_n_points decreased to occupy less 2G size. An
    object of that size is practically inoperable anyway.

Item_func_make_set wasn't taking into account the first argument when
calculating maybe_null.

sql/item_strfunc.cc:
  rewrite Item_func_make_set, removing separate storage of the first argument
sql/item_strfunc.h:
  rewrite Item_func_make_set, removing separate storage of the first argument

      The bug was found by Alyssa Milburn.
      If the number of points of a geometry feature read from
      binary representation is greater than 0x10000000, then
      the (uint32) (num_points * 16) will cut the higher byte,
      which leads to various errors.
      Fixed by additional check if (num_points > max_n_points).

MySQL Bug #12408412: GROUP_CONCAT + ORDER BY + INPUT/OUTPUT SAME USER VARIABLE = CRASH
and
MySQL Bug#14664077 SEVERE PERFORMANCE DEGRADATION IN SOME CASES WHEN USER VARIABLES ARE USED


sql/item_func.cc:
  don't use anything from Item_func_set_user_var::fix_fields()
  in Item_func_set_user_var::save_item_result()
sql/sql_class.cc:
  Call suv->save_item_result(item) *before* doing suv->fix_fields(), because
  the former evaluates the item (and caches its value), while the latter marks
  the user variable as non-const. The problem is that the item was fix_field'ed
  when the user variable was const, and it doesn't expect it to change to non-const
  in the middle of the execution.

mysys/errors.c:
  revert upstream's fix. use a much simpler one
mysys/my_write.c:
  revert upstream's fix. use a simpler one
sql/item_xmlfunc.cc:
  useless, but ok
sql/mysqld.cc:
  simplify upstream's fix
storage/heap/hp_delete.c:
  remove upstream's fix.
  we'll use a much less expensive approach.

Analysis:
Range analysis discoveres that the query can be executed via loose index scan for GROUP BY.
Later, GROUP BY analysis fails to confirm that the GROUP operation can be computed via an
index because there is no logic to handle duplicate field references in the GROUP clause.
As a result the optimizer produces an inconsistent plan. It constructs a temporary table,
but on the other hand the group fields are not set to point there.
    
Solution:
Make loose scan analysis work in sync with order by analysis. In the case of duplicate
columns loose scan will not be applicable. This limitation will be lifted in 10.0 by
removing duplicate columns.

MDEV-729 lp:998028 - Server crashes on normal shutdown in closefrm after executing a query from MyISAM table

don't write a key value into the record buffer - a key length can be larger then the record length.

MDEV-759 lp:998340 - Valgrind complains on simple selects containing expression DAY(FROM_UNIXTIME(-1))

check item->null_value before using the result of item->val_int()

This bug could result in returning 0 for the expressions of the form 
<aggregate_function>(distinct field) when the system variable  
max_heap_table_size was set to a small enough number.
It happened because the method Unique::walk() did not support
the case when more than one pass was needed to merge the trees
of distinct values saved in an external file.

Backported a fix in grant_lowercase.test from mariadb 5.5.

MDEV-4029 SELECT on information_schema using a subquery locks up the information_schema table due to incorrect mutexes handling
  
Early evaluation of subqueries in the WHERE conditions on I_S.*_STATUS tables,
otherwise the subquery on this same table will try to acquire LOCK_status twice.