WL#7076: Backporting wl6715 to support both formats in 5.5, 5.6, 5.7

         Backporting wl6715 to mysql-5.5
--BZR--
revision-id: ashish.y.agarwal@oracle.com-20130702062839-r04p0znfx6gn6cd8
property-audit-revid: ashish.y.agarwal@oracle.com-20130702062839-5ocbvyo6bxkarc9g
property-branch-nick: mysql_backport
testament3-sha1: 4a07658b94523de8ddccf73182172f103f4d5e95
Raise version number after cloning 5.5.33
--BZR--
revision-id: hery.ramilison@oracle.com-20130708174140-43eqsc2k3t0nbx21
property-audit-revid: hery.ramilison@oracle.com-20130708174140-mt1debj83p8fkdrk
property-authors: hery.ramilison@oracle.com
property-branch-nick: mysql-5.5
testament3-sha1: 0300e30dc2241d765f899f427979d96e17b1c30f
Raise version number after cloning 5.1.71
--BZR--
revision-id: murthy.narkedimilli@oracle.com-20130709111953-k3t2y554f18cbnxy
property-audit-revid: murthy.narkedimilli@oracle.com-20130709111953-xv0vlql9hk1ja3k4
property-authors: murthy.narkedimilli@oracle.com
property-branch-nick: mysql-5.1
testament3-sha1: 9aa6a55764f4d712714d936dccd46be582e7888c
Empty version change upmerge
--BZR--
revision-id: murthy.narkedimilli@oracle.com-20130709114614-yqmpco3p41kwqpi0
property-audit-revid: murthy.narkedimilli@oracle.com-20130709114614-u1x0talyqefpkpt9
property-branch-nick: mysql-5.5
testament3-sha1: 8b912a4dada8d23ce020d2abee3e85ce8f6fe010
Bug #14017206 WITH CONSISTENT SNAPSHOT DOES NOT WORK WITH ISOLATION LEVEL
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+.


--BZR--
revision-id: annamalai.gurusami@oracle.com-20130710051917-095mjguul2a2gi3j
property-audit-revid: annamalai.gurusami@oracle.com-20130710051917-nt61vp2200vdgvkn
property-branch-nick: mysql-5.5
testament3-sha1: 02ae9dfa419cbcd5b8e9886509526610b7bb908f
Fix Bug #16710923 - FALSE REPORTS OF DB_FOREIGN_EXCEED_MAX_CASCADE
                  
rb://2582 approved by Inaam

--BZR--
revision-id: jimmy.yang@oracle.com-20130710060030-ux0t7tucpbs0gaui
property-audit-revid: jimmy.yang@oracle.com-20130710060030-vpe9febm53m3249e
property-branch-nick: mysql-5.5
testament3-sha1: 34d721f61002922546733cb030f12fcd352f2d5f
Bug #17035577 - MTR V1 FAILS TO START SERVER MTR_VERSION=1 PERL MYSQL-TEST-RUN.PL 1ST
--BZR--
revision-id: sayantan.dutta@oracle.com-20130717085402-9rcup9wjqkwabusc
property-audit-revid: sayantan.dutta@oracle.com-20130717085402-bns23lc6tk9pxx1c
property-branch-nick: mysql-5.1
testament3-sha1: 39f67769b9e53f550bfe5b0bd615882d4e4cff49
upmerge bug 17035577 5.1 => 5.5
--BZR--
revision-id: sayantan.dutta@oracle.com-20130717085509-wnh5y2ijnbp0uigj
property-audit-revid: sayantan.dutta@oracle.com-20130717085509-2idex0sngcp12pn8
property-branch-nick: mysql-5.5
testament3-sha1: 62d226ddcf7376bbf826a3b1a65f3ff2b33b029d
BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING
              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.
--BZR--
revision-id: nisha.gopalakrishnan@oracle.com-20130718061008-yfgolx0c2bzuqgag
property-audit-revid: nisha.gopalakrishnan@oracle.com-20130718061008-4ebdflfhbl0ntnbh
property-branch-nick: mysql-5.1-5844882
testament3-sha1: 09d62f593e83ea06f04287834064e73233d4e74a
BUG#15844882: MYSQLDUMP FROM 5.5 FAILS WITH AN ERROR WHEN TRYING
              TO DUMP DATA FROM MYSQL-5.6 

Merge from mysql-5.1 to mysql-5.5.
--BZR--
revision-id: nisha.gopalakrishnan@oracle.com-20130718061400-fqo7gvkugikn3018
property-audit-revid: nisha.gopalakrishnan@oracle.com-20130718061400-8cvdlspjaf1csozf
property-branch-nick: mysql-5.5-15844882
testament3-sha1: bef02f5390b4dc25a548621b0cb20fc6a2429967


--BZR--
revision-id: mysql-builder@oracle.com-20130723062938-1urt5x5nlb0olsfi
property-audit-revid: thayumanavar.x.sachithanantha@oracle.com-20130723062938-g7z1ji8p71t392b8
property-branch-nick: clone
testament3-sha1: 1e4305bfbf2937dcc2d791d1c5aa3048e28dec29


--BZR--
revision-id: mysql-builder@oracle.com-20130723063300-isbglshhdsen7jyn
property-audit-revid: thayumanavar.x.sachithanantha@oracle.com-20130723063300-j0akgfxqmav27o2g
property-branch-nick: clone
testament3-sha1: 2187042a7cc6635e0f8cf8a6a8f2dbe859f3beef


--BZR--
revision-id: mysql-builder@oracle.com-20130723064557-ussweyn1redoslr8
property-audit-revid: thayumanavar.x.sachithanantha@oracle.com-20130723064557-zyako4k96x2dnh95
property-branch-nick: clone
testament3-sha1: 4f99380427112743300313926f80cfb476944ed7
BUG#16295518 - SYS_VARS.RPL_INIT_SLAVE_FUNC IS FAILING ON MYSQL-5.1 
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.

--BZR--
revision-id: astha.pareek@oracle.com-20130723124343-vrcwrn8p9sv4cmh5
property-audit-revid: astha.pareek@oracle.com-20130723124343-f90tpoldtmozgohd
property-branch-nick: mysql-5.1-b12535301
testament3-sha1: 6c5d7105ac1cd7457993075c66fbdf8589e35267
BUG#12535301- SYS_VARS.RPL_INIT_SLAVE_FUNC MISMATCHES IN DAILY-5.5

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.

--BZR--
revision-id: astha.pareek@oracle.com-20130723124819-7jogiwgvw4j1fjpt
property-audit-revid: astha.pareek@oracle.com-20130723124819-kwk2gyn3q2wdn0wu
property-branch-nick: mysql-5.5-b12535301
testament3-sha1: 74518e8d8481ac3776854f13cdfaee46dcd10d4c
Bug#16865959 - PLEASE BACKPORT BUG 14749800.

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.

--BZR--
revision-id: praveenkumar.hulakund@oracle.com-20130724101441-h09en0z0imtkj7ri
property-audit-revid: praveenkumar.hulakund@oracle.com-20130724101441-nlgahtaat6otgxdu
property-branch-nick: mysql_5_5
testament3-sha1: 706ebdd61405b82c8d2650656cb34de4364fcedf
Fix for Bug#16614004 CRASH AFTER READING FREED MEMORY AFTER DOING DDL IN STORED ROUTINE
Inside a loop in a stored procedure, we create a partitioned
table. The CREATE statement is thus treated as a prepared statement:
it is prepared once, and then executed by each iteration. Thus its Lex
is reused many times. This Lex contains a part_info member, which
describes how the partitions should be laid out, including the
partitioning function. Each execution of the CREATE does this, in
open_table_from_share ():

    tmp= mysql_unpack_partition(thd, share->partition_info_str,
                                share->partition_info_str_len,
                                outparam, is_create_table,
                                share->default_part_db_type,
                                &work_part_info_used);
 ...
      tmp= fix_partition_func(thd, outparam, is_create_table);
The first line calls init_lex_with_single_table() which creates
a TABLE_LIST, necessary for the "field fixing" which will be
done by the second line; this is how it is created:
  if ((!(table_ident= new Table_ident(thd,
                                      table->s->db,
                                      table->s->table_name, TRUE))) ||
      (!(table_list= select_lex->add_table_to_list(thd,
                                                   table_ident,
                                                   NULL,
                                                   0))))
    return TRUE;
it is allocated in the execution memory root.
Then the partitioning function ("id", stored in Lex -> part_info)
is fixed, which calls Item_ident:: fix_fields (), which resolves
"id" to the table_list above, and stores in the item's
cached_table a pointer to this table_list. 
The table is created, later it is dropped by another statement,
then we execute again the prepared CREATE. This reuses the Lex,
thus also its part_info, thus also the item representing the
partitioning function (part_info is cloned but it's a shallow
cloning); CREATE wants to fix the item again (which is
normal, every execution fixes items again), fix_fields ()
sees that the cached_table pointer is set and picks up the
pointed table_list. But this last object does not exist
anymore (it was allocated in the execution memory root of
the previous execution, so it has been freed), so we access
invalid memory.
The solution: when creating the table_list, mark that it
cannot be cached.
--BZR--
revision-id: guilhem.bichot@oracle.com-20130724123352-g16vucu34dyc21me
property-audit-revid: guilhem.bichot@oracle.com-20130724123352-vhvk2yijz2fz81dn
property-branch-nick: 5.5
testament3-sha1: 642b7cd7fba39ad8e0bfe4cbdcce998a3fb95a55
Bug #17076737 DUPLICATE CONSTRAINTS DISPLAYED WHEN NAME INCLUDES "_IBFK_"

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



--BZR--
revision-id: annamalai.gurusami@oracle.com-20130725092323-z8heiashbuha18ja
property-audit-revid: annamalai.gurusami@oracle.com-20130725092323-p4s20g1bhc0fmfep
property-branch-nick: mysql-5.1
testament3-sha1: 4b76d632fdab755b833a6e48fdad86f0bb61b863
Merge from mysql-5.1 to mysql-5.5
--BZR--
revision-id: annamalai.gurusami@oracle.com-20130725100106-ewq0hq3ythh1mfgk
property-audit-revid: annamalai.gurusami@oracle.com-20130725100106-ev695w1vyz8c7urp
property-branch-nick: mysql-5.5
testament3-sha1: f90e44f60b50cf130ccb04e023df3d9e5efc1ee7
BUG#16290902 DROP TEMP TABLE IF EXISTS CAN CAUSE POINT
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`;'.
--BZR--
revision-id: venkatesh.duggirala@oracle.com-20130727120502-k5sp0kdgyoerhm8r
property-audit-revid: venkatesh.duggirala@oracle.com-20130727120502-z4na0jvwnbs80zdb
property-branch-nick: mysql-5.5
testament3-sha1: f3eddab096282d8f392c6c189f4b36c26bf102da