Merged from mysql-5.1 to mysql-5.5

Problem description:
Table 't' created with two colums having compound index on both the 
columns under innodb/myisam engine at remote machine. In the local 
machine same table is created undet the federated engine.
A select having where clause with along 'AND' operation gives wrong 
results on local machine.

Analysis: 
The given query at federated engine is wrongly transformed by 
federated::create_where_from_key() function and the same was sent to 
the remote machine. Hence the local machine is showing wrong results.

Given query "select c1 from t where c1 <= 2 and c2 = 1;"
Query transformed, after ha_federated::create_where_from_key() function is:
SELECT `c1`, `c2` FROM `t` WHERE  (`c1` IS NOT NULL ) AND 
( (`c1` >= 2)  AND  (`c2` <= 1) ) and the same sent to real_query().
In the above the '<=' and '=' conditions were transformed to '>=' and 
'<=' respectively.

ha_federated::create_where_from_key() function behaving as below:
The key_range is having both the start_key and end_key. The start_key 
is used to get "(`c1` IS NOT NULL )" part of the where clause, this 
transformation is correct. The end_key is used to get "( (`c1` >= 2) 
AND  (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') 
are changed as wrong conditions('>=' and '<=').
The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, 
flag = HA_READ_AFTER_KEY}

The store_length is having value '5'. Based on store_length and length 
values the condition values is applied in HA_READ_AFTER_KEY switch case.
The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of 
the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, 
here the '>=' is getting added as a condition instead of '<='.

Fix:
Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all 
parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in 
the if condition.


mysql-test/suite/federated/federated.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_archive.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_bug_13118.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_bug_25714.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_bug_35333.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_debug.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_innodb.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_server.test:
  modified the federated.inc file location
mysql-test/suite/federated/federated_transactions.test:
  modified the federated.inc file location
mysql-test/suite/federated/include/federated.inc:
  moved the file from federated suite to federated/include folder
mysql-test/suite/federated/include/federated_cleanup.inc:
  moved the file from federated suite to federated/include folder
mysql-test/suite/federated/include/have_federated_db.inc:
  moved the file from federated suite to federated/include folder
storage/federated/ha_federated.cc:
  updated the 'if condition' in ha_federated::create_where_from_key() 
  function.

PROBLEM: 
mysql provides a feature where in a session which is 
idle for a period specified by the wait_timeout variable
(whose value is in seconds), the session is closed
This feature is not present when we use thread pool.
FIX:
This patch implements the interface functions which is 
required to implement the wait_timeout functionality
in the thread pool plugin.

"warning: integer constant is too large for 'long' type"

Backporting the WL#5716, "Information schema table for InnoDB 
buffer pool information". Backporting revisions 2876.244.113, 
2876.244.102 from mysql-trunk.

rb://1175 approved by Jimmy Yang. 

Backporting the WL#5716, "Information schema table for InnoDB
buffer pool information". Backporting revisions 2876.244.113,
2876.244.102 from mysql-trunk.

rb://1177 approved by Jimmy Yang. 

Problem: Valgrind reports errors when an invalid certificate is used on the
         client.

Solution: Updated yaSSL to version 2.2.2.

'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". 

mysys/mf_iocache.c:
  Added debug statement to simulate a scenario where the cache
  file's current position is set to >4GB
sql/log.cc:
  Replaced the type of `saved_max_binlog_cache_size' from "ulong" to
  "my_off_t", which is a type def for "ulonglong".

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!


support-files/mysql.spec.sh:
  Add the "runselftest" macro following the model provided by RedHat.
  
  This code is similar to what we plan to use for ULN RPMs.

while the copyright notice still mentioned 2003.

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.

No commit message

No commit message

  Added new minimal client using same framework
  Added internal test using it
  Small changes to top level make/configure/cmake to have it built

Merged from mysql-5.1 to mysql-5.5

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'".

client/mysql.cc:
  com_server_help(): Properly updated the server_cmd variable and improved
  the error message.

                     "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


mysql-test/r/subselect.result:
  Changes for Bug#11762052 results in the correct number of rows.
sql/sql_select.cc:
  Do not pass the actual 'limit' value if 'need_tmp' is true.

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 "./".

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().

No commit message

No commit message

              COUNT DISTINCT GROUP BY

PROBLEM:
To calculate the final result of the count(distinct(select 1))
we call 'end_send' function instead of 'end_send_group'.
'end_send' cannot be called if we have aggregate functions
that need to be evaluated.

ANALYSIS:
While evaluating for a possible loose_index_scan option for
the query, the variable 'is_agg_distinct' is set to 'false'
as the item in the distinct clause is not a field. But, we
choose loose_index_scan by not taking this into 
consideration.
So, while setting the final 'select_function' to evaluate
the result, 'precomputed_group_by' is set to TRUE as in
this case loose_index_scan is chosen and we do not have
agg_distinct in the query (which is clearly wrong as we
have one).
As a result, 'end_send' function is chosen as the final
select_function instead of 'end_send_group'. The difference
between the two being, 'end_send_group' evaluates the
aggregates while 'end_send' does not. Hence the wrong result.

FIX:
The variable 'is_agg_distinct' always represents if 
'loose_idnex_scan' can be chosen for aggregate_distinct 
functions present in the select.
So, we check for this variable to continue with 
loose_index_scan option.


sql/opt_range.cc:
  Do not continue if is_agg_distinct is not set in case
  of agg_distinct functions.

follow-up patch for the failure on pb2 windows build

Follow up patch to resolve pb2 failure on windows platform

             primary key with innodb tables

The bug was triggered if a single ALTER TABLE statement both
added and dropped indexes and ALTER TABLE failed during drop
(e.g. because the index was needed in a foreign key constraint).
In such cases, the server index information would get out of
sync with InnoDB - the added index would be present inside
InnoDB, but not in the server. This could then lead to InnoDB
error messages and/or server crashes.

The root cause is that new indexes are added before old indexes
are dropped. This means that if ALTER TABLE fails while dropping
indexes, index changes will be reverted in the server but not
inside InnoDB.

This patch fixes the problem by dropping any added indexes
if drop fails (for ALTER TABLE statements that both adds
and drops indexes). 

However, this won't work if we added a primary key as this
key might not be possible to drop inside InnoDB. Therefore,
we resort to the copy algorithm if a primary key is added
by an ALTER TABLE statement that also drops an index.

In 5.6 this bug is more properly fixed by the handler interface
changes done in the scope of WL#5534 "Online ALTER".

No commit message

No commit message

KEY UPDATES WITH A LIMIT OF 1

Problem: The unsafety warning for statements such as
update...limit1 where pk=1 are thrown when binlog-format
= STATEMENT,despite of the fact that such statements are
actually safe. this leads to filling up of the disk space 
with false warnings.
 
Solution: This is not a complete fix for the problem, but
prevents the disks from getting filled up. This should
therefore be regarded as a workaround. In the future this
should be overriden by server general suppress/filtering
framework. It should also be noted that another worklog is
supposed to defeat this case's artificial unsafety.

We use a warning suppression mechanism to detect warning flood,
enable the suppression, and disable this when the average
warnings/second has reduced to acceptable limits.
 
  Activation: The supression for LIMIT unsafe statements are
  activated when the last 50 warnings were logged in less 
  than 50 seconds. 
 
  Supression: Once activated this supression will prevent the
  individual warnings to be logged in the error log, but print
  the warning for every 50 warnings with the note:
  "The last warning was repeated N times in last S seconds"  
  Noteworthy is the fact that this supression works only on the
  error logs and the warnings seen by the clients will remain as
  it is (i.e. one warning/ unsafe statement)
 
  Deactivation: The supression will be deactivated once the
  average # of warnings/sec have gone down to the acceptable limits.



sql/sql_class.cc:
  Added code to supress warning while logging them to error-log.