It's safe to delete from HASH when traversing it *backwards*, but not *forwards*.

The fix for mdev-4420 was not quite correct. This patch corrects it.

mysql-test/suite/rpl/r/last_insert_id.result:
  Test case for last_insert_id
mysql-test/suite/rpl/t/last_insert_id.cnf:
  Test case for last_insert_id
mysql-test/suite/rpl/t/last_insert_id.test:
  Test case for last_insert_id
sql/log_event.cc:
  Added DBUG_PRINT
  Set thd->first_successful_insert_id_in_prev_stmt_for_binlog when setting thd->first_successful_insert_id_in_prev_stmt.
  This is required to get last_insert_id() replicated.
  This is analog to how read_first_successful_insert_id_in_prev_stmt() works.
sql/rpl_utility.cc:
  Added DBUG_PRINT

When in function remove_eq_conds() a sub-formula of the processed condition
is replaced for another formula we should ensure that in the resulting
formula AND/OR levels must alternate.

The patch to fix mdev-4418 turned out to be incorrect.
At the substitution of single row tables in make_join_statistics()
the used multiple equalities may change and references to the new multiple
equalities must be updated. The function remove_eq_conds() takes care of it and
it should be called right after the substitution of single row tables.
Calling it after the call of make_join_statistics was a mistake.

Made sure that degenerate conjunctions/disjunctions are obtained from
AND/OR conditions.

The code of JOIN::optimize that performed substitutions for the best equal
field in all ref items did not take into account that a multiple equality
could contain the result of the single-value subquery if the subquery is
inexpensive. This code was corrected.
Also made necessary corresponding corrections in the code of make_join_select().

pending merges:
  Alexander Barkov 2013-08-22 MDEV-4804 Date comparing false result

Fix two problems in table elimination code:
- Before marking a "value" as bound, check if it is already bound. Marking the 
  same value as bound twice could confuse a module that depends on this value, 
  because Dep_module_XXX use counters to know when they become bound.

- When checking whether field is part of a key, ignore "extended keys" property.

MDEV-4908: Assertion `((Item_cond *) cond)->functype() == ((Item_cond *) new_item)->functype()' fails on a query with IN and equal conditions, AND/OR, materialization+semijoin

A new AND Item should be prepared (fix_field() call) before using.

had been merged into 5.5.

Corrected the result of the output from the test case for mdev 4895.

Fix bug MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL

Analysis:
The cause of the valgrind warning was an attempt to evaluate a Field that was not yet read.
The reason was that on one hand Item_func_isnotnull was marked as constant by
Item_func_isnotnull::update_used_tables, and this allowed eval_const_cond() to be called.
On the other hand Item_func_isnotnull::val_int() evaluated its argument as if it was not
constant.

Solution:
The fix make sure that Item_func_isnotnull::val_int() doesn't evaluate its argument when
it is constant and cannot be NULL, because the result is known in this case. 

MDEV-4923 Incorrect merge on XtraDB os0file.c. Function os_file_set_atomic_writes returns TRUE when successfull and FALSE at failure.

had been discovered when merging the patch from 5.3 into 5.5.

In particular:
Merged the patch for bug mdev-4418 from 5.3 into 5.5.
Fixed a bug in the patch that should be backported to 5.3.

support -DTMPDIR=/path in CMakeLists.txt

Patch by Honza Horak.

After single row substitutions there might appear new equalities.
They should be properly propagated to all AND/OR levels the WHERE
condition. It's done now with an additional call of remove_eq_conds(). 

This patch almost totally revised the patch for bug mdev-4177.
The latter had too many defects. In particular, it did not
propagate multiple equalities formed when merging a degenerate
disjunct into underlying AND formula.

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.
 

modified:
  mysql-test/r/dyncol.result
  mysql-test/r/type_time.result
  mysql-test/t/dyncol.test
  mysql-test/t/type_time.test
  mysys/ma_dyncol.c
  sql/item.cc
  sql/item_func.cc
pending merges:
  Alexander Barkov 2013-08-12 MDEV-4652 Wrong result for CONCAT(GREATEST(T...
    sanja@montyprogr... 2013-08-01 MDEV-4811 Assertion `offset < 0x1f' f...

set num_flag[] unconditionally, not under "if (column_names)"

http://ronaldbradford.com/blog/unexplained-trivial-mysql-behavior-2013-08-02/

pending merges:
  Alexander Barkov 2013-08-08 MDEV-4653 Wrong result for CONVERT_TZ(TIME('...

pending merges:
  Alexander Barkov 2013-08-08 MDEV-4512 Valgrind warnings in my_long10_to_...