Merge from mysql-5.1 into mysql-5.5

Problem:
=======
It was detected an incorrect behavior of my_strtoll10 function when 
converting strings with numbers in the following format:
"184467440XXXXXXXXXYY"

Where XXXXXXXXX > 737095516 and YY <= 15

Samples of problematic numbers:
"18446744073709551915"
"18446744073709552001"

Instead of returning the larger unsigned long long value and setting overflow
in the returned error code, my_strtoll10 function returns the lower 64-bits 
of the evaluated number and did not set overflow in the returned error code.

Analysis:
========
Once trying to fix bug 16820156, I've found this bug in the overflow check of
my_strtoll10 function.

This function, once receiving a string with an integer number larger than
18446744073709551615 (the larger unsigned long long number) should return the
larger unsigned long long number and set overflow in the returned error code.

Because of a wrong overflow evaluation, the function didn't catch the
overflow cases where (i == cutoff) && (j > cutoff2) && (k <= cutoff3). When
the overflow evaluation fails, the function return the lower 64-bits of the
evaluated number and do not set overflow in the returned error code.

Fix:
===
Corrected the overflow evaluation in my_strtoll10.

      
Description:
Original fix Bug#11765744 changed mutex to read write lock
to avoid multiple recursive lock acquire operation on 
LOCK_status mutex.  
On Windows, locking read-write lock recursively is not safe. 
Slim read-write locks, which MySQL uses if they are supported by
Windows version, do not support recursion according to their 
documentation. For our own implementation of read-write lock, 
which is used in cases when Windows version doesn't support SRW,
recursive locking of read-write lock can easily lead to deadlock
if there are concurrent lock requests.
      
Fix:  
This patch reverts the previous fix for bug#11765744 that used
read-write locks. Instead problem of recursive locking for
LOCK_status mutex is solved by tracking recursion level using 
counter in THD object and acquiring lock only once when we enter 
fill_status() function first time. 

Description:
Original fix Bug#11765744 changed mutex to read write lock
to avoid multiple recursive lock acquire operation on 
LOCK_status mutex.  
On Windows, locking read-write lock recursively is not safe. 
Slim read-write locks, which MySQL uses if they are supported by
Windows version, do not support recursion according to their 
documentation. For our own implementation of read-write lock, 
which is used in cases when Windows version doesn't support SRW,
recursive locking of read-write lock can easily lead to deadlock
if there are concurrent lock requests.

Fix:  
This patch reverts the previous fix for bug#11765744 that used
read-write locks. Instead problem of recursive locking for
LOCK_status mutex is solved by tracking recursion level using 
counter in THD object and acquiring lock only once when we enter 
fill_status() function first time. 

             SHUTDOWN IS IN PROGRESS 

[ Null Merge from mysql-5.1]

             SHUTDOWN IS IN PROGRESS 

PROBLEM
-------
 In the background thread srv_master_thread() we have a 
 a one second delay loop which will continuously monitor
 server activity .If the server is inactive (with out any
 user activity) or in a shutdown state we do some background
 activity like flushing the changes.In the current code
 we are not checking if server is in shutdown state before
 sleeping for one second.

FIX
---
If server is in shutdown state ,then dont go to one second
sleep. 

              PARTITIONS.

ANALYSIS
--------
Whenever we query I_S.partitions,
ha_partition::get_dynamic_partition_info()
is called which resets the cardinality 
according to the number of rows in last
partition.

Fix
---
When we call get_dynamic_partition_info() 
avoid passing the flag HA_STATUS_CONST
to info() since HA_STATUS_CONST should 
ideally not be called for per partition.

[Approved by mattiasj rb#2830 ]

IN TIME RECOVERY FAILURE ON SLAVES

Problem:
DROP TEMP TABLE IF EXISTS commands can cause point
in time recovery (re-applying binlog) failures.

Analyses:
In RBR, 'DROP TEMPORARY TABLE' commands are
always binlogged by adding 'IF EXISTS' clauses.
Also, the slave SQL thread will not check replicate.* filter
rules for "DROP TEMPORARY TABLE IF EXISTS" queries.
If log-slave-updates is enabled on slave, these queries
will be binlogged in the format of "USE `db`;
DROP TEMPORARY TABLE IF EXISTS `t1`;" irrespective
of filtering rules and irrespective of the `db` existence.
When users try to recover slave from it's own binlog,
use `db` command might fail if `db` is not present on slave.

Fix:
At the time of writing the 'DROP TEMPORARY TABLE
IF EXISTS' query into the binlog, 'use `db`' will not be
present and the table name in the query will be a fully
qualified table name.
Eg:
'USE `db`; DROP TEMPORARY TABLE IF EXISTS `t1`;'
will be logged as
'DROP TEMPORARY TABLE IF EXISTS `db`.`t1`;'.

Problem:

When the user specified foreign key name contains "_ibfk_", InnoDB wrongly
tries to rename it. 

Solution:

When a table is renamed, all its associated foreign keys will also be renamed,
only if the foreign key names are automatically generated.  If the foreign key
names are given by the user, even if it has _ibfk_ in it, it must not be
renamed.

rb#2935 approved by Jimmy, Krunal and Satya

Since log_throttle is not available in 5.5. Logging of
error message for failure of thread to create new connection
in "create_thread_to_handle_connection" is not backported.

Since, function "my_plugin_log_message" is not available in 
5.5 version and since there is incompatibility between
sql_print_XXX function compiled with g++ and alog files with
gcc to use sql_print_error, changes related to audit log
plugin is not backported.

Problem:
sys_vars.rpl_init_slave_func test was failing sporadically 
on 5.5+.

Fix:
Added assert condition after wait for checks.
Recorded test and enabled it.

BUG#12535301- SYS_VARS.RPL_INIT_SLAVE_FUNC MISMATCHES IN DAILY-5.5 

Problem:
sys_vars.rpl_init_slave_func test was not recorded after
the last edit. It was disabled on 5.1 after seeing failures
due to the above reason.
No old failures as this suite never ran with pb2 on 5.1

Fix:
Added assert condition after wait for checks.
Recorded test and enabled it.

No commit message

No commit message

No commit message

              TO DUMP DATA FROM MYSQL-5.6 

Merge from mysql-5.1 to mysql-5.5.

              TO DUMP DATA FROM MYSQL-5.6

Analysis
--------
Dumping mysql-5.6 data using mysql-5.1/mysql-5.5 'myqldump'
utility fails with a syntax error.

Server system variable 'sql_quote_show_create' which quotes the
identifiers is set in the mysqldump utility. The mysldump utility
of mysql-5.1/mysql-5.5 uses deprecated syntax 'SET OPTION' to set
the 'sql_quote_show_create' option. The support for the syntax is
removed in mysql-5.6. Hence syntax error is reported while taking
the dump.

Fix:
---
Changed the 'mysqldump' code to use the syntax
'SET SQL_QUOTE_SHOW_CREATE' to set the 'sql_quote_show_create'
option. That syntax is supported on mysql-5.1, mysql-5.5 and
mysql-5.6.

NOTE: I have not added an mtr test case since it is difficult
to simulate the condition. Also the syntax may not be further
simplified in the future.

                  
rb://2582 approved by Inaam

SERIALIZABLE

Problem:

The documentation claims that WITH CONSISTENT SNAPSHOT will work for both
REPEATABLE READ and SERIALIZABLE isolation levels.  But it will work only
for REPEATABLE READ isolation level.  Also, the clause WITH CONSISTENT
SNAPSHOT is silently ignored when it is not applicable to the given isolation
level.  

Solution:

Generate a warning when the clause WITH CONSISTENT SNAPSHOT is ignored.

rb#2797 approved by Kevin.

Note: Support team wanted to push this to 5.5+.

             MULTI-FILE TABLESPACE

ANALYSIS
--------

When a tablespace has multiple data files, InnoDB fails to 
open the tablespace.  This is because for each ibd file, 
the first page is checked.But the first page of all ibd file
need not be the first page of the tablespace.  Only the first
page of the tablespace contains the tablespace header. When 
we check the first page of an ibd file that is not the first
page of the tablespace, then the "tablespace flags" is not
really available.This was wrongly used to check if a page is
corrupt or not.

FIX
---
Use the tablespace flags only if the page number is 0 
in a tablespace.  

[Approved by Inaam rb#2836 ]

                WITH UTF8_UNICODE_CI COLLATION
Problem Description:
When comparing datetime values with strings, the utf8_unicode_ci collation 
prevents correct comparisons. Consider the below set of queries, it is not 
showing any results on a table which has tuples that satisfies the query. 
But for collation utf8_general_ci it shows one tuple.
set names utf8 collate utf8_unicode_ci;;
select * from lang where dt='1979-12-09';

Analysis:
The comparison function is not chosen in case of collation utf8_unicode_ci.
In agg_item_set_converter() because the collation state is having 
"MY_CS_NONASCII" for collation type "utf8_unicode_ci". The conversion 
of the collation is happening for the date field. And because of that 
it is unable to pickup proper compare function(i.e CMP_DATE_WITH_STR).

Actually the bug is accidentally introduced by the WL#3759 in 5.5. 
And in 5.6 it is been fixed by the WL#3664.

Fix:
I have backported the changes from the file strings/ctype-uca.c which 
are related to "utf8" introduced by the WL#3664.
This change helps in choosing the correct comparison function for all 
the collations of utf8 charset.

Cleanup test case (left outfile in data dir)

No commit message

ALTER TABLE ... ALGORITHM= ... STATEMENT

The problem was an intermediate buffer of smaller size,
which truncated the alter statement.

Solved by providing the size of the buffer to be allocated through
the function call, instead of using an one-size-fits-all stack buffer
inside the function.

Bug16785036 - RPM REQUIRES: MISSING PACKAGES ON RHEL 6 (AND PROBABLY 5)
Bug 16878042 - CANNOT KEEP SEVERAL MAJOR VERSIONS OF MYSQL IN THE SAME YUM REPOSITORY

Backported the deprecation warnings from WL#6978 to 5.5

Problem:

The problem is that explain_filename-t is not printing a test plan as
required by the TAP protocol. The test invokes plan(NO_PLAN) but does not
invoke exit_status() at the end, where the plan would be printed.

Solution:

Invoke exit_status() at the end.

Straight forward backport.

Approved by Jimmy, rb#2656

No commit message

LOAD DATA CAN CAUSE SQL INJECTION

Problem:
=======
A long SET expression in LOAD DATA is incorrectly truncated
when written to the binary log.

Analysis:
========
LOAD DATA statements are reconstructed once again before
they are written to the binary log. When SET clauses are
specified as part of LOAD DATA statement, these SET clause
user command strings need to be stored as it is inorder to
reconstruct the original user command.  At present these
strings are stored as part of SET clause item tree's
top most Item node's name itself which is incorrect. As an
Item::name can be of MAX_ALIAS_NAME (256) size. Hence the
name will get truncated to "255".

Because of this the rewritten LOAD DATA statement will be
terminated incorrectly.  When this statment is read back by
the mysqlbinlog tool it reads a starting single quote and
continuos to read till it finds an ending quote. Hence any
statement written post ending quote will be considered as
a new statement.

Fix:
===
As name field has length restriction the string value
should not be stored in Item::name.  A new String list is
maintained to store the SET expression values and this list
is read during reconstrution.

sql/sql_lex.cc:
  Clear the load data set string list during each query 
  execution.
sql/sql_lex.h:
  Added a new String list to store the load data operation's
  SET clause user command strings.
sql/sql_load.cc:
  Read the SET clause user command strings from load data
  set string list.
sql/sql_yacc.yy:
  Store the SET caluse user command string as part of load
  data set string list.