Buffer over-run on all platforms, crash on windows, wrong result on other platforms,
when rounding numbers which start with 999999999 and have
precision = 9 or 18 or 27 or 36 ...


mysql-test/r/type_newdecimal.result:
  New test cases.
mysql-test/t/type_newdecimal.test:
  New test cases.
sql/my_decimal.h:
  Add sanity checking code, to catch buffer over/under-run.
strings/decimal.c:
  The original initialization of intg1 (add 1 if buf[0] == DIG_MAX)
  will set p1 to point outside the buffer, and the loop to copy the original value
      while (buf0 < p0)
        *(--p1) = *(--p0);
  will overwrite memory outside the my_decimal object.

adjust/modify tests as they were failing if system time zone is set differently.

bug#11766457 - adjusting/modifying the the tests as tests were failing if system time zone is set differently.

because the search pattern for the "INFO_*" files was not general enough:
Fixed.

 
A buffer large enough to hold the query _plus_ some additional
data is allocated before parsing is started.   The additional data 
is used by the query cache, and consists of the name of the current 
database and a set of flags.
 
When a packet containing multiple SQL statements is sent to the
server and one of the statements changes the current database
(a "USE <db>" statement), and the name of the new current database 
is longer than of the previous,  there is not enough space in the 
buffer for the new name, and we write out over the buffer boundary.

The fix adds an extra field to store the number of bytes
allocated to the database name in the buffer.  If the current
database name changes, and the new name is longer than the
previous one, we refuse to cache the query.

       
Sun Studio 12 has an error when calculating the compile-time 
length of a constant character string.  The error is only 
present when building an optimized 32-bits version, using 
the -xbuiltin=(%all) compiler flag. 
       
During compilation, the compiler recognizes the use of 
the strlen() function used on a constant string. It 
optimizes the strlen and replaces it with the actual 
length of the string.   This optimization seems to 
calculate the length wrongly in this particular case. 
       
Replacing the "const char *" with a "const char []" 
solves the problem. 

but the latter only takes one argument, duh!
Fixed by concatenating the args (replace , with .)

  This is a redo for 5.5
  Added 'innodb_file_format_max' as variable to ignore change to.
  Tests that had to restore this amended
  Two tests assumed it to be Antelope, make sure these run on a freshly
    started server

Problematic query:
insert ignore into `t1_federated` (`c1`) select `c1` from  `t1_local` a
where not exists (select 1 from `t1_federated` b where a.c1 = b.c1);
When this query is killed in another connection it could lead to crash.
The problem is follwing:
An attempt to obtain table statistics for subselect table in killed query
fails with an error. So JOIN::optimize() for subquery is failed but
it does not prevent further subquery evaluation.
At the first subquery execution JOIN::optimize() is called
(see subselect_single_select_engine::exec()) and fails with
an error. 'executed' flag is set to TRUE and it prevents
further subquery evaluation. At the second call
JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE
and in case of uncacheable subquery the 'executed' flag is set
to FALSE before subquery evaluation. So we loose 'optimize stage'
error indication (see subselect_single_select_engine::exec()).
In other words 'executed' flag is used for two purposes, for
error indication at JOIN::optimize() stage and for an
indication of subquery execution. And it seems it's wrong
as the flag could be reset.


mysql-test/r/error_simulation.result:
  test case
mysql-test/t/error_simulation.test:
  test case
sql/item_subselect.cc:
  added new flag subselect_single_select_engine::optimize_error
  which is used for error detection which could happen at optimize
  stage.
sql/item_subselect.h:
  added new flag subselect_single_select_engine::optimize_error
sql/sql_select.cc:
  test case

rw_lock_x_lock_func(): Assert that the thread is not already holding
the lock in a conflicting mode (RW_LOCK_SHARED).

rw_lock_s_lock_func(): Assert that the thread is not already holding
the lock in a conflicting mode (RW_LOCK_EX).