Analysis:
Constant table optimization of the outer query finds that
the right side of the equality is a constant that can
be used for an eq_ref access to fetch one row from t1,
and substitute t1 with a constant. Thus constant optimization
triggers evaluation of the subquery during the optimize
phase of the outer query.

The innermost subquery requires a plan with a temporary
table because with InnoDB tables the exact count of rows
is not known, and the empty tables cannot be optimzied
way. JOIN::exec for the innermost subquery substitutes
the subquery tables with a temporary table.

When EXPLAIN gets to print the tables in the innermost
subquery, EXPLAIN needs to print the name of each table
through the corresponding TABLE_LIST object. However,
the temporary table created during execution doesn't
have a corresponding TABLE_LIST, so we get a null
pointer exception.

Solution:
The solution is to forbid using expensive constant
expressions for eq_ref access for contant table
optimization. Notice that eq_ref with a subquery
providing the value is still possible during regular
execution.

Analysis:
During the first execution of the query through the stored
procedure, the optimization phase calls
substitute_for_best_equal_field(), which calls
Item_in_optimizer::transform(). The latter replaces
Item_in_subselect::left_expr with args[0] via assignment.
In this test case args[0] is an Item_outer_ref which is
created/deallocated for each re-execution. As a result,
during the second execution Item_in_subselect::left_expr
pointed to freed memory, which resulted in a crash.

Solution:
The solution is to use change_item_tree(), so that the
origianal left expression is restored after each execution.

Analysis:
Partial matching is used even when there are no NULLs in
a materialized subquery, as long as the left NOT IN operand
may contain NULL values.

This case was not handled correctly in two different places.
First, the implementation of parital matching did not clear
the set of matching columns when the merge process advanced
to the next row.

Second, there is no need to perform partial matching at all
when the left operand has no NULLs.

Solution:
First fix subselect_rowid_merge_engine::partial_match() to
properly cleanup the bitmap of matching keys when advancing
to the next row.

Second, change subselect_partial_match_engine::exec() so
that when the materialized subquery doesn't contain any
NULLs, and the left operand of [NOT] IN doesn't contain
NULLs either, the method returns without doing any
unnecessary partial matching. The correct result in this
case is in Item::in_value.

sql/sql_select.cc:
  items' cmp_type()'s must match, not result_type()'s

When the WHERE/HAVING condition of a subquery has been transformed
by the optimizer the pointer stored the 'where'/'having' field 
of the SELECT_LEX structure used for the subquery must be updated
accordingly. Otherwise the pointer may refer to an invalid item.
This can lead to the reported assertion failure for some queries
with correlated subqueries   

The bug is a duplicate of MySQL's Bug#11764086,
however MySQL's fix is incomplete for MariaDB, so
this fix is slightly different.

In addition, this patch renames
Item_func_not_all::top_level() to is_top_level_item()
to make it in line with the analogous methods of
Item_in_optimizer, and Item_subselect.

Analysis:
It is possible to determine whether a predicate is
NULL-rejecting only if it is a top-level one. However,
this was not taken into account for Item_in_optimizer.
As a result, a NOT IN predicate was erroneously
considered as NULL-rejecting, and the NULL-complemented
rows generated by the outer join were rejected before
being checked by the NOT IN predicate.

Solution:
Change Item_in_optimizer to be considered as
NULL-rejecting only if it a top-level predicate.

opt_range.cc: modified print_key() so that it doesn't do memory re-allocs when
printing multipart keys over varchar columns. When it did, key printout in 
debug trace was interrupted with my_malloc/free printouts.

BUG#826935 Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed
- add_ref_to_table_cond() should not just overwrite pre_idx_push_select_cond
  with the contents tab->select_cond.
  pre_idx_push_select_cond exists precisely for the reason that it may contain
  a condition that is a strict superset of what is in tab->select_cond. 
  The fix is to inject generated equality into pre_idx_push_select_cond.

The value of maybe_null flag should be saved for the second execution
of a prepared statement from SELECT that uses an outer join.

- Make simplify_joins() set maybe_null=FALSE for tables that were on the 
  inner sides of inner joins and then were moved to the inner sides of semi-joins.

If mysqld --log-warnings=3 or higher, then print all check and repair warnings for MyISAM tables to the log.
This is useful when trying to find out why an automatic myisam repair failes.

storage/myisam/ha_myisam.cc:
  If mysqld --log-warnings=3 or higher, then print all check and repair warnings for MyISAM tables to the error log.

Fixed bug that MAX_USER_CONNECTIONS was not working properly in all situations (which could cause aborted connects)
thd->user_connect is now handled in thd->clenup() which will ensure that it works in all context (including slaves).
I added also some DBUG_ASSERT() to ensure that things are working correctly.


sql/sql_acl.cc:
  Reset thd->user_connect on failed check_for_max_user_connections() to ensure we don't decrement value twice.
  Removed not needed call to decrease_user_connections() as thd->cleanup() will now do it.
sql/sql_class.cc:
  Call decrease_user_connections() in thd->cleanup()
sql/sql_connect.cc:
  Ensure we don't allocate thd->user_connect twice.
  Simplify check_for_max_user_connections().
sql/sql_parse.cc:
  Ensure that thd->user_connect is handled properly in for 'change_user' command.

storage/maria/ma_recovery.c:
  Moved trman_init() before parse_checkpoint_record() as this calls trnman functions if we have to open tables.

The bug was that when using bulk insert combined with lock table, we intitalized the io cache with the wrong file position.
This fixed a bug where MariaDB could not read in a table dump done with mysqldump.


mysql-test/suite/maria/r/locking.result:
  Test case for locking + write cache bug
mysql-test/suite/maria/t/locking.test:
  Test case for locking + write cache bug
storage/maria/ma_extra.c:
  Initialize write cache used with bulk insert to correct file length.
  (The old code didn't work if one was using LOCK TABLE for the given table).

Fixes bugs found by testcase for lp:815022 and lp:726374 "ma_blockrec.c:3000: write_block_record: Assertion `cur_block[1].page_count == 0' failed with a multi-index Aria workload"
The issues was:
- For some tables with a lot of not packed fields, we didn't allocate enough memory in head page which caused DBUG_ASSERT's
- Removed wrong DBUG_ASSERT()
- Fixed a problem with underflow() where it generates a key page where all keys didn't fit.
- Max key length is now limited by block_size/3  (was block_size /2).  This is required for underflow() to work with packed keys.




mysql-test/lib/v1/mysql-test-run.pl:
  Remove --alignment=8 as this doesn't work on 64 bit systems
mysql-test/suite/maria/r/small_blocksize.result:
  Test case for Aria bug
mysql-test/suite/maria/t/small_blocksize-master.opt:
  Test case for Aria bug
mysql-test/suite/maria/t/small_blocksize.test:
  Test case for Aria bug
storage/maria/ha_maria.cc:
  Fixed comment
storage/maria/ma_bitmap.c:
  Fixed wrong variable usage in find_where_to_split_row() where we allocated too little memory for head page.
  We did not take into account space for head extents (long VARCHAR) when trying to split row on head page. This caused us to allocate too little space from bitmap which lead to ASSERT failures later.
storage/maria/ma_blockrec.c:
  Made some argument const (to ensure they was not accidently changed)
  Removed wrong DBUG_ASSERT()
storage/maria/ma_blockrec.h:
  Removed not used variable
storage/maria/ma_delete.c:
  Added my_afree() in case of error
  More comments and DBUG_ASSERT() for underflow()
storage/maria/ma_open.c:
  Make keyinfo->underflow_block_length smaller for packed keys. This has to be done as for long packed keys, underflow() otherwise generates a key page where all keys didn't fit.
storage/maria/ma_page.c:
  New DBUG_ASSERT()
storage/maria/ma_write.c:
  Fixed comment
storage/maria/maria_def.h:
  We have to have space for at least 3 keys on a key page.
  (Otherwise the underflow() code doesn't work for packed keys, even when we have an underflow() for an empty key page)

Fixed lp:814231 Aria post-recovery error "Bitmap at page 0 has pages reserved outside of data file length"
The bug was a wrong check in aria_chk;  The table was fine.


storage/maria/ma_bitmap.c:
  Print whole bitmap to find errors in last bitmap
storage/maria/ma_check.c:
  Fixed wrong test if bitmap was overallocated.

sql/sql_expression_cache.cc:
  Early check of subquery cache hit rate added to limit its performance impact in the worst case.
  Disabling cache moved to method.
sql/sql_expression_cache.h:
  Disabling cache moved to method.

  
Identified all test cases in the MySQL file subquery.inc that are
not present in MariaDB. This patch adds the test cases that are:
- not present in MySQL 5.5, and
- already fixed in MariaDB 5.3

The patch adds test cases for the following mysql-trunk bugs:
- Bug#12763207 - not a bug, mysql-trunk, added test case
- BUG#50257    - not a bug, mysql-trunk, added test case
- Bug 11765699 - not a bug, mysql-trunk, added test case
- BUG#12616253 - not a bug, mysql-trunk, added test case

The comparison was based on the following version of
  mysql-trunk:
  
  revno: 3350 [merge]
  committer: Marko Mäkelä <marko.makela@oracle.com>
  branch nick: mysql-trunk
  timestamp: Mon 2011-08-08 12:42:09 +0300
  message:
    Merge mysql-5.5 to mysql-trunk.

The method Item_ref::not_null_tables() returned incorrect bitmap
for outer references to view columns. This could cause an invalid
conversion of an outer join into an inner join that could lead
to a wrong result set for a query with a correlated subquery over
an outer join whose where condition had an outer reference to a view.

The method Item_func_isnull::update_used_tables() erroneously did not
update cached values stored in the fields used_tables_cache and
const_item_cache of the Item_func_isnull objects. As a result the
Item_func_isnull::used_tables() returned wrong bitmaps and, as a
consequence, push-down predicates could be attached to wrong tables.

Fixed bug lp:814054 'Assertion `block->hash_link == hash_link && hash_link->block == block' in ma_pagecache.c:2275 with Aria'
- Replaced old DBUG_ASSERT with a new correct one + a comment.

storage/maria/ma_pagecache.c:
  Replaced old DBUG_ASSERT with a new correct one + a comment.

This fixes a bug that when you use mysqldump --no-create-info to generate a dump that you want to merge with an existing table,
you can get an innodb table with duplicated unique keys.
Patch orignally by Eric Bergen.


client/mysqldump.c:
  Only use UNIQUE_CHECKS=0 for tables that are created.
  This solves the issue that you can't get duplicate unique keys when merging two dumps.
mysql-test/r/mysqldump.result:
  Test for mysqldump --no-create-info

Identified all test cases in the MySQL file subquery_mat.inc that are
not present in MariaDB. In total found 8 test cases for the following
MySQL bugs:
* BUG#49630 - not a bug in MariaDB, added test case
* BUG#52538 - not a bug in MariaDB, added test case (checked with VG)
* BUG#53103 - not a bug in MariaDB, added test case
* BUG#54511 - not a bug in MariaDB, added test case
* BUG#56367 - not a bug in MariaDB, added test case
* BUG#59833 - not a bug in MariaDB, added test case
* BUG#11852644 - not a bug in MariaDB, added test case
* BUG#12668294 - not a bug in MariaDB, added test case

All of these MySQL bugs are not present in MariaDB 5.3.

The comparison was based on the following version of
mysql-trunk:

revno: 3350 [merge]
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: mysql-trunk
timestamp: Mon 2011-08-08 12:42:09 +0300
message:
  Merge mysql-5.5 to mysql-trunk.

This bug is a special case of lp:813447.

Analysis:
Constant optimization finds that the condition t2.a = 1
can be used to access the primary key of table 't2'. As
a result both outer table t1,t2 are considered as constant
when we reach the execution phase. At the same time, during
constant optimization, the IN predicate is not evaluated
because it is expensive.

When execution of the outer query reaches do_select(),
control flow enter the branch:
if (join->table_count == join->const_tables)
{ ... }
This branch checks only the WHERE and HAVING clauses,
but doesn't check the ON clauses of the query. Since the
IN predicate was not evaluated during optimization, it is
not evaluated at all, thus execution doesn't detect that
the ON clause is FALSE.

Solution:
Similar to the patch for bug lp:813447, exclude system
tables from constant substitution based on unique key
lookups if there is an expensive ON condition on the
inner table.

Do not optimize derived table for the second time ever.