BUG#13555854: CHECK AND REPAIR TABLE SHOULD BE MORE ROBUST [1]

ISSUE: Incorrect key file. Key file is corrupted,
       Reading incorrect key information (keyseg)
       from index file. Key definition in .MYI
       and .FRM file differs. Starting pointer
       to read the keyseg information is changed
       to a value greater than the pack_reclength.
       Memcpy tries to read keyseg information from
       unallocated memory which causes the crash.

SOLUTION: One more check added to compare the
          the key definition in .MYI and .FRM
          file. If the definition differ, server
          produces an error.
Raise version number after cloning 5.5.27
Bug #11765218 58157: INNODB LOCKS AN UNMATCHED ROW EVEN THOUGH USING
RBR AND RC

Description: When scanning and locking rows with < or <=, InnoDB locks
the next row even though row based binary logging and read committed
is used.

Solution: In the handler, when the row is identified to fall outside
of the range (as specified in the query predicates), then request the
storage engine to unlock the row (if possible). This is done in
handler::read_range_first() and handler::read_range_next().
Merging from mysql-5.1 to mysql-5.5. 
BUG#14310067: RPL_CANT_READ_EVENT_INCIDENT AND RPL_BUG41902 FAIL ON 5.5

rpl_cant_read_event_incident:
Slave applies updates from bug11747416_32228_binlog.000001 file which 
contains a CREATE TABLE t statement and an incident, when SQL thread is
running slowly IO thread may reach the incident before SQL thread
executes the create table statement. 
Execute "drop table if exists t" and also perform a RESET MASTER to
clean slave binary logs.

rpl_bug41902:
Error "MYSQL_BIN_LOG::purge_logs was called with file
./master-bin.000001 not listed in the index." suppression is not 
considering windows path, there is ".\master-bin.000001".
Changed suppression to: "MYSQL_BIN_LOG::purge_logs was called with file
..master-bin.000001 not listed in the index", to match ".\" and "./".
Bug#11762052: 54599: BUG IN QUERY PLANNER ON QUERIES WITH
                     "ORDER BY" AND "LIMIT BY" CLAUSE

PROBLEM:
When a 'limit' clause is specified in a query along with
group by and order by, optimizer chooses wrong index
there by examining more number of rows than required.
However without the 'limit' clause, optimizer chooses
the right index.

ANALYSIS:
With respect to the query specified, range optimizer chooses
the first index as there is a range present ( on 'a'). Optimizer
then checks for an index which would give records in sorted
order for the 'group by' clause.

While checking chooses the second index (on 'c,b,a') based on
the 'limit' specified and the selectivity of
'quick_condition_rows' (number of rows present in the range)
in 'test_if_skip_sort_order' function. 
But, it fails to consider that an order by clause on a
different column will result in scanning the entire index and 
hence the estimated number of rows calculated above are 
wrong (which results in choosing the second index).

FIX:
Do not enforce the 'limit' clause in the call to
'test_if_skip_sort_order' if we are creating a temporary
table. Creation of temporary table indicates that there would be
more post-processing and hence will need all the rows.

This fix is backported from 5.6. This problem is fixed in 5.6 as   
part of changes for work log #5558
Merge from 5.1 to 5.5
Bug #12615411 - server side help doesn't work as first statement

Problem description:
Giving "help 'contents'" in the mysql client as a first statement
gives error

Analysis:
In com_server_help() function the "server_cmd" variable was
initialised with buffer->ptr(). And the "server_cmd" variable is not
updated since we are passing "'contents'"(with single quote) so the
buffer->ptr() consists of the previous buffer values and it was sent
to the mysql_real_query() hence we are getting error.

Fix:
We are not initialising the "server_cmd" variable and we are updating
the variable with "server_cmd= cmd_buf" in any of the case i.e with
single quote or without single quote for the contents.
As part of error message improvement, added new error message in case
of "help 'contents'".
Bug #12615411 - server side help doesn't work as first statement

Merged from mysql-5.1 to mysql-5.5
Bug #14035452 - MODULARIZE MYSQL_CLIENT_TEST
  Added new minimal client using same framework
  Added internal test using it
  Small changes to top level make/configure/cmake to have it built
upmerge 14035452 5.1 -> 5.5
Reverting broken configure/make stuff
null upmerge
BUG#13555854: CHECK AND REPAIR TABLE SHOULD BE MORE ROBUST [1]

ISSUE: Incorrect key file. Key file is corrupted,
       Reading incorrect key information (keyseg)
       from index file. Key definition in .MYI
       and .FRM file differs. Starting pointer
       to read the keyseg information is changed
       to a value greater than the pack_reclength.
       Memcpy tries to read keyseg information from
       unallocated memory which causes the crash.

SOLUTION: One more check added to compare the
          the key definition in .MYI and .FRM
          file. If the definition differ, server
          produces an error.
Fixing wrong copyright. Index.xml was modified in 2005,
while the copyright notice still mentioned 2003.
Merging from 5.1
Fix bug#14318456  SPEC FILE DOES NOT RUN THE TEST SUITE DURING RPM BUILD

Add a macro "runselftest" to the spec file for RPM builds.

If its value is 1 (the default), the test suite will be run during
the RPM build.
To prevent that, add this to the rpmbuild command line:
    --define "runselftest 0"
Failures of the test suite will NOT make the RPM build fail!
Bug#13961678:MULTI-STATEMENT TRANSACTION REQUIRED MORE THAN
'MAX_BINLOG_CACHE_SIZE' ERROR
      
Problem:
=======
MySQL returns following error in win64.
"ERROR 1197 (HY000): Multi-statement transaction required more than
'max_binlog_cache_size' bytes of storage; increase this mysqld variable
and try again" when user tries to load >4G file even if
max_binlog_cache_size set to maximum value. On Linux everything
works fine.
      
Analysis:
========
The `max_binlog_cache_size' variable is of type `ulonglong'.  This
value is set to `ULONGLONG_MAX' at the time of server start up. The
above value is stored in an intermediate variable named
`saved_max_binlog_cache_size' which is of type `ulong'. In visual
c++ complier the `ulong' type is of 4bytes in size and hence the value
is getting truncated to '4GB' and the cache is not able to grow beyond
4GB size. The same limitation is observed with 
"max_binlog_stmt_cache_size" as well. Similar fix has been applied.
      
Fix:
===
As part of fix the type "ulong" is replaced with "my_off_t" which is of
type "ulonglong".