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.

test suite added.

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.

MDEV-3952 Incompatible change in MariaDB-5.5.28a-client rpm adds mytop when not in MariaDB-5.5.23-client (CentOS 5)

Same as for deb: don't add mytop to the client rpm.

MDEV-3934 Assertion `((keypart_map+1) & keypart_map) == 0' failed in _mi_pack_key with an index on a POINT column

sel_arg_range_seq_next(): set keypart map also for GEOM_FLAG keys

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.

sql/item.h:
  remove unused method

MDEV-3832 MariaDB conflicts with packages filesystem-3.1-2.fc18.i686 and jre-1.7.0_09-fcs.i586 on Fedora 18

fix the rpm packaging to work on Fedora18. Two problems:
* conflicts on common directories with other packages.
* more auto-generated requirements for mariadb-test.rpm

initialize cache_mngr and write the Xid into binlog even
if binlog is disabled with SQL_LOG_BIN=0 or no --log-slave-updates
in the slave thread

Add a test case.
The fix comes with MySQL bug#15948123: SERVER WORKS INCORRECT WITH LONG TABLE ALIASES

Fix Windows installers' bootstrapper scripts ,  after mysql_performance_tables.sql was  split off mysql_system_tables.sql

This fixed failing test in group_by.test

mysql-test/r/join_outer.result:
  Updated test case
mysql-test/r/join_outer_jcl6.result:
  Updated test case
sql/item.cc:
  Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
sql/item.h:
  Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
sql/item_cmpfunc.h:
  Don't reset maybe_null in update_used_tables(); This breaks ROLLUP

The problem was that maybe_null of Item_row and its componetes was unsynced after update_used_tables() (and so pushed_cond_guards was not initialized but then requested).

Fix  updates Item_row::maybe_null on update_used_tables().

MDEV-3900 Optimizer difference between MySQL and MariaDB with stored functions in WHERE clause of UPDATE or DELETE statements

Analysis
The reason for the less efficient plan was result of a prior design decision -
to limit the eveluation of constant expressions during optimization to only
non-expensive ones. With this approach all stored procedures were considered
expensive, and were not evaluated during optimization. As a result, SPs didn't
participate in range optimization, which resulted in a plan with table scan
rather than index range scan.

Solution
Instead of considering all SPs expensive, consider expensive only those SPs
that are non-deterministic. If an SP is deterministic, the optimizer will
checj if it is constant, and may eventually evaluate it during optimization.

Don't reset maybe_null in update_used_tables(); This breaks ROLLUP
This fixed failing test in group_by.test

Subquery turned into constant too late to be excluded from grouping list so test for constant added to the create_temp_table().

The original patch with the implementation of virtual columns
did not support INSERT DELAYED into tables with virtual columns.
This patch fixes the problem.

(because it's conceptually wrong. only the user can decide whether the kill is
allowed to leave tables in the inconsistent state, storage engine has no say in that)

The previous fix for MDEV-3992 was incomplete, because it still computed
incorrectly the number of keyparts of the extended secondary key in the
case when columns of the PK participate in the secondary key.

This patch by Monty corrects the above problem.

Analysis:
  The crash is a result of incorrect analysis of whether a secondary key
  can be extended with a primary in order to compute ORDER BY. The analysis
  is done in test_if_order_by_key(). This function doesn't take into account
  that the primary key may in fact index the same columns as the secondary
  key. For the test query test_if_order_by_key says that there is an extended
  key with total 2 keyparts.
  At the same time, the condition
    if (pkinfo->key_part[i].field->key_start.is_set(nr))
  in test_if_cheaper_oredring() becomes true for (i == 0), which results in
  an invalid access to rec_per_key[-1].
  
Solution:
  The best solution would be to reuse KEY::ext_key_parts that is already computed
  by open_binary_frm(), however after detailed analysis the conclusion is that
  the change would be too intrusive for a GA release.
  The solution for 5.5 is to add a guard for the case when the 0-th key part is
  considered, and to assume that all keys will be scanned in this case.