sql/signal_handler.cc:
  Added missing signal values.

Fixed supression in mysql-test-run so it also works on windows.

mysql-test/mysql-test-run.pl:
  Fixed supression so it also works on windows.
mysql-test/valgrind.supp:
  More general handling of memory loss in dlclose (backported from 5.2)
sql/signal_handler.cc:
  Added newlines around link to how to do bug reports

"safe exception patch".
Remove misleading comments suggesting about signal() Windows, the routine here
is part of a exception handler, and sig parameter is an exception code.

mysql-test/suite/innodb/t/innodb_bug51920.test:
  Add another possible connect error

Fixed README with link to source
Merged InnoDB change to XtraDB

README:
  Added information of where to find MariaDB code
storage/archive/ha_archive.cc:
  Removed memset() of rows, a MariaDB checksum's doesn't touch not used data.

This happend when you have more than 1024 open Aria tables during checkpoint.


mysql-test/mysql-test-run.pl:
  Fixed that variable names are consistent between external and internal server.
mysql-test/suite/maria/suite.pm:
  Test for aria-block-size instead of 'aria' as 'aria' is not set for embedded server.
  This should be ok for aria tests, as aria is never disabled for these.
storage/maria/ma_checkpoint.c:
  Fixed bug when there are more than 1024 open Aria tables during checkpoint.

BUG#933407: Valgrind warnings in mark_as_null_row with materialization+semijoin, STRAIGHT_JOIN, impossible WHERE
- In return_zero_rows(), don't call mark_as_null_row() for semi-join 
  materialized tables, because 1) they may have been already freed, and 
  2)there is no real need to call mark_as_null_row() for them.
  

This bug is the result of an incomplete/inconsistent change introduced into
5.3 code when the cond_equal parameter were added to the function optimize_cond.
The change was made during a merge from 5.2 in October 2010.
The bug could affect only queries with HAVING.

An outer join query with a semi-join subquery could return a wrong result
if the optimizer chose to materialize the subquery.
It happened because when substituting for the best field into a ref item
used to build access keys not all COND_EQUAL objects that could be employed
at substitution were checked.

Also refined some code in the function check_join_cache_usage to make it
safer. 

common icp callback in the handler.cc.

It can also increment status counters, without making the engine
dependent on the exact THD layout (that is different in embedded).

This bug led to wrong values of the use_count fields in some SEL_ARG
trees that triggered complains on the server side when executing the
test case for LP bug 800184 if a debug build of the server was used.
  
This was the result of the incomplete fix for bug 800184.
To complete it the following corrections had to be made:
- the copy constructor for SEL_TREE must call the new function incr_refs_all()
  instead of the function incr_refs(), because references to next key parts
  from any SEL_ARG tree belonging to the list of the first key part has to be
  adjusted.
- the method and_sel_tree of the class SEL_IMERGE must use the copy constructor
  of the SEL_TREE class to make a copy of its second argument before it ANDs it
  with any SEL_TREE tree from the processed SEL_IMERGE object.  
   

The bug was fixed with the code back-ported from the patch for LP bug 800184
pushed into mariadb-5.3.

timestamp: Thu 2011-12-01 15:12:10 +0100
Fix for Bug#13430436 PERFORMANCE DEGRADATION IN SYSBENCH ON INNODB DUE TO ICP

When running sysbench on InnoDB there is a performance degradation due
to index condition pushdown (ICP). Several of the queries in sysbench
have a WHERE condition that the optimizer uses for executing these
queries as range scans. The upper and lower limit of the range scan
will ensure that the WHERE condition is fulfilled. Still, the WHERE
condition is part of the queries' condition and if ICP is enabled the
condition will be pushed down to InnoDB as an index condition. 

Due to the range scan's upper and lower limits ensure that the WHERE
condition is fulfilled, the pushed index condition will not filter out
any records. As a result the use of ICP for these queries results in a
performance overhead for sysbench. This overhead comes from using
resources for determining the part of the condition that can be pushed
down to InnoDB and overhead in InnoDB for executing the pushed index
condition.

With the default configuration for sysbench the range scans will use
the primary key. This is a clustered index in InnoDB. Using ICP on a
clustered index provides the lowest performance benefit since the
entire record is part of the clustered index and in InnoDB it has the
highest relative overhead for executing the pushed index condition.

The fix for removing the overhead ICP introduces when running sysbench
is to disable use of ICP when the index used by the query is a
clustered index.

When WL#6061 is implemented this change should be re-evaluated.

Problem was that now we can merge derived table (subquery in the FROM clause).
Fix: in case of detected conflict and presence of derived table "over" the table which cased the conflict - try materialization strategy.

tests for RTree keys recovery.

- Make equality propagation work correctly when done inside the OR branches 

If the flag 'optimize_join_buffer_size' is set to 'off' and the value
of the system variable 'join_buffer_size' is greater than the value of
the system variable 'join_buffer_space_limit' than no join cache can
be employed to join tables of the executed query.
A bug in the function JOIN_CACHE::alloc_buffer allowed to use join
buffer even in this case while another bug in the function 
revise_cache_usage could cause a crash of the server in this case if the
chosen execution plan for the query contained outer join or semi-join
operation.  

locked until we have finished clean up.

Previously, the code released the lock without marking that the thread
was running. This allowed a new slave thread to start while the old one
was still in the middle of cleaning up, causing assertions and probably
general mayhem.

Protocol documentation (http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol)
says that initial packet sent by client if client wants SSL, consists of client capability flags only
(4 bytes or 2 bytes edependent on protocol versionl). 
Some clients happen to send more in the initial SSL packet (C client, Python connector), while others (Java, .NET) follow the docs and send only client capability flags.

A change that broke Java client was a newly introduced check that frst client packet
has 32 or more bytes. This is generally wrong, if client capability flags contains CLIENT_SSL.

Also, fixed the code such that read max client packet size and charset in the first packet prior to SSL handshake.  With SSL, clients do not have to send this info, they can only send client flags.

This is now fixed such that max packet size and charset are not read prior to SSL handshake, in case of SSL they are read from the "complete" client authentication packet after SSL initialization.