mysqldump with --include-master-host-port putting quotes around port number
Patch from Stewart Smith

client/mysqldump.c:
  Remove quotes from MASTER_PORT

Fixed MDEV-306 / LP:1007967 - Assertion `table->file->stats.records > 0 || error' failed join_read_const_table on concurrent SELECT and DROP/ADD INDEX


sql/sql_table.cc:
  Added comment
storage/maria/ma_close.c:
  Don't store history if it's visible to all.
  This fixed the MDEV-306 bug
storage/maria/ma_delete_table.c:
  Removed old comment
  Delete history state for deleted tables
storage/maria/ma_info.c:
  More DBUG_PRINT
storage/maria/ma_open.c:
  More DBUG_PRINT

- Add the VIA_SYM token into keyword_sp list, which makes it allowed for
  use as keyword and SP label.

The bug prevented acceptance of UNION queries whose non-first select 
clauses contained join expressions with degenerated single-table nests
as valid queries.
The bug was introduced into mysql-5.5 code line by the patch for
bug 33204.

Fixed MDEV-331: last_insert_id() returns a signed number

mysql-test/r/auto_increment.result:
  Added test case
mysql-test/t/auto_increment.test:
  Added test case
sql/item_func.h:
  Changed last_insert_id() to be unsigned.

LP1008334 : Speedup specific datetime queries that got slower with introduction of microseconds in 5.3

- Item::get_seconds() now skips decimal arithmetic, if decimals is 0. This significantly speeds up from_unixtime() if no fractional part is passed.
- replace sprintfs used to format temporal values  by hand-coded formatting 
  
Query1 (original query in the bug report)
BENCHMARK(10000000,DATE_SUB(FROM_UNIXTIME(RAND() * 2147483648), INTERVAL (FLOOR(1 + RAND() * 365)) DAY)) 
  
Query2 (Variation of query1 that does not use fractional part in FROM_UNIXTIME parameter)
BENCHMARK(10000000,DATE_SUB(FROM_UNIXTIME(FLOOR(RAND() * 2147483648)), INTERVAL (FLOOR(1 + RAND() * 365)) DAY)) 
  
Prior to the patch, the runtimes were (32 bit compilation/AMD machine)
Query1: 41.53 sec 
Query2: 23.90 sec
  
With the patch, the runtimes are
Query1: 32.32 sec (speed up due to removing sprintf)
Query2: 12.06 sec (speed up due to skipping decimal arithmetic)

The --debug-no-sync incorrectly defaulted to ON, disabling sync calls
by default which can loose data or cause corruption. Also, the code
used fsync() instead of the sometimes more efficient fdatasync().

Analysis:

When the method JOIN::choose_subquery_plan() decided to apply
the IN-TO-EXISTS strategy, it set the unit and select_lex
uncacheable flag to UNCACHEABLE_DEPENDENT_INJECTED unconditionally.
As result, even if IN-TO-EXISTS injected non-correlated predicates,
the subquery was still treated as correlated.

Solution:
Set the subquery as correlated only if the injected predicate(s) depend
on the outer query.

remove the offending assert.
take the test case from mysql Bug#58015

backport dmitry.shulga@oracle.com-20120209125742-w7hdxv0103ymb8ko from mysql-trunk:

  Patch for bug#11764747 (formerly known as 57612): SET GLOBAL READ_ONLY=1 cannot
  progress when a table is locked with LOCK TABLES.
  
  The reason for the bug was that mysql server makes a flush of all open tables
  during handling of statement 'SET GLOBAL READ_ONLY=1'. Therefore if some of
  these tables were locked by "LOCK TABLE ... READ" from a different connection,
  then execution of statement 'SET GLOBAL READ_ONLY=1' would be waiting for
  the lock for such table even if the table was locked in a compatible read mode.
  
  Flushing of all open tables before setting of read_only system variable
  is inherited from 5.1 implementation since this was the only possible approach
  to ensure that there isn't any pending write operations on open tables.
  
  Start from version 5.5 and above such behaviour is guaranteed by the fact
  that we acquire global_read_lock before setting read_only flag. Since
  acquiring of global_read_lock is successful only when there isn't any 
  active write operation then we can remove flushing of open tables from
  processing of SET GLOBAL READ_ONLY=1.
  
  This modification changes the server behavior so that read locks held
  by other connections (LOCK TABLE ... READ) no longer will block attempts
  to enable read_only.

Take only test cases from MDEV-136 Non-blocking "set read_only"

Analysis:
The crash is a result of Item_cache_temporal::example not being set
(it is NULL). It turns out that the value of Item_cache_temporal
may be set directly by calling Item_cache_temporal::store_packed
without ever setting the "example" of this Item_cache. Therefore
the failing assertion is too narrow.

Solution:
Remove the assert.
In principle we could overwrite this method for Item_cache_temporal,
but it doesn't make sense just for this assert.

- Set index columns to be read when using index_merge, even if TABLE->no_keyread is 
  set for the table (happens for multi-table UPDATEs)

The constructor for Query_log_event allocated 2 bytes too few for
extra space needed by Query cache. (Not sure if this is reproducible
in practice, as there are often a couple of extra bytes allocated
for unused string zero terminators, but better safe than sorry).

Analysis:

When a subquery that needs a temp table is executed during
the prepare or optimize phase of the outer query, at the end
of the subquery execution all the JOIN_TABs of the subquery
are replaced by a new JOIN_TAB that selects from the temp table.
However that temp table has no corresponding TABLE_LIST.
Once EXPLAIN execution reaches its last phase, it tries to print
the names of the subquery tables through its TABLE_LISTs, but in
the case of this bug there is no such TABLE_LIST (it is NULL),
hence a crash.

Solution:
The fix is to block subquery evaluation inside
Item_func_like::fix_fields and Item_func_like::select_optimize()
using the Item::is_expensive() test.

Otherwise yum on fedora will not install them
(rpm will, yum on centos and rhel will).

Build MariaDB-compat rpm by repackaging files from MariaDB-shared-5.3.*.rpm
Or RHEL6/CentOS6 make all other MariaDB rpms depend on MariaDB-compat.

        Optimizator fails using index with ST_Within(g, constant_poly).

per-file comments:
  mysql-test/r/gis-rt-precise.result
        test result fixed.
  mysql-test/r/gis-rtree.result
        test result fixed.
  mysql-test/suite/maria/r/maria-gis-rtree-dynamic.result
        test result fixed.
  mysql-test/suite/maria/r/maria-gis-rtree-trans.result
        test result fixed.
  mysql-test/suite/maria/r/maria-gis-rtree.result
        test result fixed.
  storage/maria/ma_rt_index.c
        Use MBR_INTERSECT mode when optimizing the select WITH ST_Within.
  storage/myisam/rt_index.c
        Use MBR_INTERSECT mode when optimizing the select WITH ST_Within.

but restart it on upgrade, if it was already running

use my.cnf includes to split one big my.cnf file in server and client parts.

remove "Provides: mysql-libs" (doesn't help on CentOS 6)

could lead an to exponential growth of the imerge lists.

- In JOIN::exec(), make the having->update_used_tables() call before we've
  made the JOIN::cleanup(full=true) call. The latter frees SJ-Materialization
  structures, which correlated subquery predicate items attempt to walk afterwards.

- Correct testcases.

- Disable IndexConditionPushdown for reverse scans.

  
  Analysis:
  The optimizer detects an empty result through constant table optimization.
  Then it calls return_zero_rows(), which in turns calls inderctly
  Item_maxmin_subselect::no_rows_in_result(). The latter method set "value=0",
  however "value" is pointer to Item_cache, and not just an integer value.
  
  All of the Item_[maxmin | singlerow]_subselect::val_XXX methods does:
    if (forced_const)
      return value->val_real();
  which of course crashes when value is a NULL pointer.
  
  Solution:
  When the optimizer discovers an empty result set, set
  Item_singlerow_subselect::value to a FALSE constant Item instead of NULL.