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.

No commit message

Sys_var_keycache inherits from some variant of Sys_var_integer

Instances of Sys_var_keycache are initialized using the KEYCACHE_VAR macro,
which takes an offset within st_key_cache.
However, the Sys_var_integer CTOR treats the offset as if it was within
global_system_variables (hidden within some layers of macros and fuction
pointers)

The result is that we write arbitrary data to arbitrary locations in memory.
This all happens during static initialization of global objects,
i.e. before we have even entered the main() function.


Bug#12325449 TYPO IN CMAKE/DTRACE.CMAKE
Fix typo in dtrace.cmake

[Merge from 5.1]

Analysis
--------
The pthread_mutex commit_threads_m was initiliazed but never
used. 

Fix
---
Removing the commit_threads_m mutex from the code base.

[ Approved by Marko rb#2475]

DDL AND I_S QUERIES

Skip partially created indexes (ones whose name starts with TEMP_INDEX_PREFIX)
from stats gathering.

Because InnoDB reports HA_INPLACE_ADD_INDEX_NO_WRITE to MySQL, the latter
allows parallel execution of ha_innobase::add_index() and ha_innobase::info().

Reviewed by:	Inaam (rb:2613)

No commit message

No commit message

No commit message

No commit message

IF IT HAS A WRONG COUNT

If CHECK TABLE finds that a secondary index contains the wrong
number of entries, it used to report an error but not mark the
index as corrupt. The error means that the index should be rebuilt,
which can be done with ALTER TABLE DROP INDEX and ALTER TABLE ADD
INDEX.  But just in case the DBA does not pay any attention to the
output of CHECK TABLE, the secondary index should be marked as
corrupted so that it is not used again.

Approved by Inaam in RB:2607

Backport to 5.5


sql/sql_table.cc:
  gcc asan crashes in filename_to_tablename() on this: memcmp("-@", "#sql", 4)
  during loading of the innobase plugin

No commit message

Backport to 5.5
(external Bug#69407 Build warnings with mysql)


support-files/build-tags:
  Run etags on sql_yacc.yy, ignore other .yy files
unittest/mysys/explain_filename-t.cc:
  NO_PLAN seems to fail on some platforms, use the actual number instead.

No commit message

             TO INCONSISTENCY 
[Merge from 5.1]

             TO INCONSISTENCY 

PROBLEM
--------
When we drop a partitoned table , we first gather the
information about partitions in the table from the 
table_name.par file and store it in an internal data 
structure.Then we delete this file and the data in 
the table. If the server crashes  after deleting the
file,then after recovering we cannot access the table
.Even we cannot drop the table ,because drop algorithm
requires par file to read the partition information.


FIX
---
1. We move the part of deleting par file after deleting 
   all the table data from the storage egine.
2. During drop operation if we detect that the par 
   file is missing then we delete the .frm file,since 
   there is no way of recovering without par file.
  
[Approved by Mattias rb#2576 ]