When storing a NULL to a TIMESTAMP NOT NULL DEFAULT ...,
NULL returned from some functions threw a 'cannot be NULL error.'

NULL-returns now correctly result in the timestamp-field being
assigned its default value.

conflicts:
  Text conflict in mysql-test/suite/sys_vars/r/rpl_max_binlog_size_func.result
  Text conflict in mysql-test/suite/sys_vars/t/rpl_max_binlog_size_func.test

 - Increase number of transaction objects available in ndbd
 - Most likely this is a timing related issue.

Temporarily blocking to run the test on windows.

Todo: remove the include upon setup_fake_relay_log has been fixed.

BUG#41003 reached our trees.

            
If the system time is adjusted back during a query execution
(resulting in the end time being earlier than the start time)
the code that prints to the slow query log gets confused and 
prints unsigned negative numbers.
            
Fixed by not logging the statements that would have negative
execution time due to time shifts.
No test case since this would involve changing the system time.

      
After the earlier fix, mtr tests reports "table full" messages as warnings. This is 
expected, this patch fixes the mtr testframework to ignore the error message.

Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
whether subquery produced any records, this was a documented limitation.

The limitation has been removed (see bugs 8804, 24085, 24127) now
Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
Item_in_optimizer::is_null() invoke val_int() to return correct values for
"NULL IN (SELECT ...)".

            messed up

"ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE.

Item_in_subselect::row_value_transformer rewrites "ROW(...)
IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)"
form.
For a subquery from the DUAL pseudotable resulting HAVING
condition is an expression on constant values, so further
transformation with optimize_cond() eliminates this HAVING
condition and resets JOIN::having to NULL.
Then JOIN::exec treated that NULL as an always-true-HAVING
and that caused a bug.

To distinguish an optimized out "HAVING TRUE" clause from
"HAVING FALSE" we already have the JOIN::having_value flag.
However, JOIN::exec() ignored JOIN::having_value as described
above as if it always set to COND_TRUE.

The JOIN::exec method has been modified to take into account
the value of the JOIN::having_value field.

 - Fix faulty regex used for filtering out suspicious warnings, causing
   warnings/errors from previous tests to be reported

Dirty close tricky does not work on Windows.

BUG#42383 2009-01-28 lsoares 
"This fails in embedded and on windows. Note that this test is not run 
on windows and on embedded in PB for main trees currently"

      
When using CREATE TEMPORARY TABLE LIKE to create a temporary table, 
or using TRUNCATE to delete all rows of a temporary table, they 
did not set the tmp_table_used flag, and cause the omission of
"SET @@session.pseudo_thread_id" when dumping binlog with mysqlbinlog,
and cause error when replay the statements.
      
This patch fixed the problem by setting tmp_table_used in these two
cases. (Done by He Zhenxing 2009-01-12)

      
Re-generated the PKI files needed.
Removed the ones that are not needed.
Updated the tests to reference the correct SSL subject.

Check for existence of diff fails on Solaris due to unsupported "-v"
Fix is to do this check only on Windows where it was needed

When a MEMORY table is full the error is returned to client but not written
to error log.

Fixed the handler api to write the error mesage to error log when the table is
full.

Note: No TestCase included as testing the error log is non-trivial.

 - Disable the two patterns that previously have been faulty - for now.

 - Improve error message for "found warnings in server log file"