On 64-bit Windows: querying MERGE table with keys may cause
server crash.The problem is generic and may affect any statement
accessing MERGE table cardinality values.
When MERGE engine was copying cardinality statistics, it was
using incorrect size of element in cardinality statistics array
(sizeof(ptr)==8 instead of sizeof(ulong)==4), causing access
of memory beyond of the allocated bounds.

The fix is to allow myisamchk to use >4G key_buffer_size on win64

doesn't find 'logger'

Due to a variable quoting mistake, the $PATH environment
variable isn't parsed correctly when searching for the
existence of the desired executable(s) (logger in this 
case).

This patch removes the quotes.

The problem is that the server failed to follow the rule that
every X509 object retrieved using SSL_get_peer_certificate()
must be explicitly freed by X509_free(). This caused a memory
leak for builds linked against OpenSSL where the X509 object
is reference counted -- improper counting will prevent the
object from being destroyed once the session containing the
peer certificate is freed.

The solution is to explicitly free every X509 object used.

HAVING
            
When calculating GROUP BY the server caches some expressions. It does
that by allocating a string slot (Item_copy_string) and assigning the 
value of the expression to it. This effectively means that the result
type of the expression can be changed from whatever it was to a string.
As this substitution takes place after the compile-time result type 
calculation for IN but before the run-time type calculations, 
it causes the type calculations in the IN function done at run time 
to get unexpected results different from what was prepared at compile time.
                  
In the CASE ... WHEN ... THEN ... statement there was a similar problem
and it was solved by artificially adding a STRING argument to the set of 
types of the IN/CASE arguments at compile time, so if any of the 
arguments of the CASE function changes its type to a string it will 
still be covered by the information prepared at compile time.

stop/start slave
      
When stopping and restarting the slave while it is replicating
temporary tables, the server would crash or raise an assertion
failure. This was due to the fact that although temporary tables are
saved between slave threads restart, the reference to the thread in
use (table->in_use) was not being properly updated when the restart
happened (it would still reference the old/invalid thread instead of
the new one).
      
This patch addresses this issue by resetting the reference to the new
slave thread on slave thread restart.

Created new .test file - mysqldump_restore that does test restore from mysqldump
output for a limited number of basic cases.
Create new .inc file - mysqldump.inc - renames original table and uses mysqldump
output to recreate the table, then uses diff_tables.inc to compare the two tables.
Backported include/diff_tables.inc to facilitate this testing.
New patch incorporating review feedback prior to push.

mysqldump.test - removed redundant call to include/have_log_bin.inc (was used twice in the test!)

            assertion .\filesort.cc, line 797

Minor fix to test case (embedded server failure).

            assertion .\filesort.cc, line 797

A query with the "ORDER BY @@some_system_variable" clause,
where @@some_system_variable is NULL, causes assertion
failure in the filesort procedures.

The reason of the failure is in the value of
Item_func_get_system_var::maybe_null: it was unconditionally
set to false even if the value of a variable was NULL.

Created new .test file - mysqldump_restore that does this for a limited number
of basic cases.
Created new .inc file - mysqldump.inc - renames original table and uses mysqldump
output to recreate the table, then uses diff_tables.inc to compare the two tables.
Backported include/diff_tables.inc to facilitate this testing.

Since max_allowed_packet is a read-only variable in 5.1 and up,
disable warnings to avoid unnecessary test case complication.

Set max_allowed_packet to get a consistent error message.

        bug#44766: valgrind error when using convert() in a subquery

Problem: input and output buffers may be the same 
converting a string to some charset. 
That may lead to wrong results/valgrind warnings.  

Fix: use different buffers.

             warnings after uncompressed_length 
 
UNCOMPRESSED_LENGTH() did not validate its argument. In 
particular, if the argument length was less than 4 bytes, 
an uninitialized memory value was returned as a result. 
 
Since the result of COMPRESS() is either an empty string or 
a 4-byte length prefix followed by compressed data, the bug was 
fixed by ensuring that the argument of UNCOMPRESSED_LENGTH() is 
either an empty string or contains at least 5 bytes (as done in 
UNCOMPRESS()). This is the best we can do to validate input 
without decompressing. 

Change the warning message to 'Statement may not be safe to log in
statement format' to indicate that the decision on whether a
statement is safe or not is heuristic, and we are conservative.

Internal InnoDN FK parser does not recognize '\'' as quotation symbol.
Suggested fix is to add '\'' symbol check for quotation condition
(dict_strip_comments() function).