BUG#17066269: AUTO_INC VALUE NOT PROPERLY GENERATED WITH RBR AND
AUTO_INC COLUMN ONLY ON SLAVE

In RBR, if the slave's table as one additional auto_inc column,
then, it will insert the value 0 instead of generating the next
auto_inc number.

We fix this by checking that if an auto_inc extra column exists,
when compared to column data of the row event, we explicitly set
it to NULL and flag the engine that a nulled auto_inc column will
be inserted.
Raise version number after cloning 5.5.36
Bug #17503460 MYSQL READ ONLY DOESN'T WORK FOR DROP TRIGGER

Problem: Drop Trigger succeeds even after setting read_only 
variable to ON.
Fix: Fix is to report the standard error 
(ER_OPTION_PREVENTS_STATEMENT)when global read_only variable 
is set to ON.
BUG#17324415:GETTING MYSQLD --HELP AS ROOT EXITS WITH 1

Analysis
--------

Running 'MYSQLD --help --verbose' as ROOT user without
using '--user' option displays the help contents but
aborts at the end with an exit code '1'.

While starting the server, a validation is performed to
ensure when the server is started as root user, it should
be done using '--user' option. Else we abort. In case
of help, we dump the help contents and abort.

Fix:
---
During the validation, we skip aborting the server incase
we are using the help option under the condition mentioned
above.

NOTE: Test case has not been added since it requires using 
      'root' user.
Bug#16715064 MYSQL COMMUNITY UTILITIES CANNOT CONNECT TO MYSQL ENTERPRISE
WITH SSL ENABLED
Problem:
It was reported that MySQL community utilities cannot connect to a MySQL
Enterprise 5.6.x server with SSL configured. We can reproduce the issue
when we try to connect an MySQL Enterprise Server with a MySQL Client with
--ssl-ca parameter enabled.
We get an ERROR 2026 (HY000): SSL connection error: unknown error number.

Solution:
The root cause of the problem was determined to be the difference in handling
of the certificates by OpenSSL(Enterprise) and yaSSL(Community). OpenSSL expects
a blank certificate to be sent when a parameter (ssl-ca, or ssl-cert or ssl-key)
has not been specified.On the other hand yaSSL doesn't send any certificate and 
since OpenSSL does not expect this behaviour it returns an Unknown SSL error.
The issue was resolved by yaSSL adding capability to send blank certificate when
any of the parameter is missing.
Bug#16287752    INNODB_DATA_FILE_PATH MINIMUM SIZE 
                IN DOCUMENTATION
Problem 
-------
The documentation says that we support 'K' prefix 
while specifiying size for innodb datafile in the
server variable for innodb_data_file_path ,but the
function srv_parse_megabytes() only handles only 
'M' (megabytes) and 'G' (gigabytes) .

Fix
---
Modify srv_parse_megabytes() to handle Kilobytes. 

Add in documentation that while specifying size 
in KB it should be mentioned in multiples of 1024
other wise they will be rounded off to nearest
MB (megabyte) boundry .(eg if size mentioned
as 2313KB will be considered as 2 MB ).

[ Approved by Marko #rb 2387 ]
Bug #17307201 : FAILING ASSERTION: PREBUILT->TRX->CONC_STATE == 1
                FROM SUBSELECT
ISSUE         : In function find_all_keys.
                If selected row do not satisfy condition
                then we call unlock_row to release the locked
                row. Suppose if we have subquery in condition
                and we have an innodb error during its execution.
                Then we should not call the unlock_row. If the error
                is because of deadlock, innodb will rollback the
                transaction. And calling unlock_row without
                transaction is an invalid case hence an assertion
                failure.
SOLUTION      : We call unlock_row only if only there is no
                error occurred previously.
                The solution is back ported from 5.6
                defect number 14226481
updating the current copyright year which reflects in the MySQL welcome message.
BUG#17066269

- Automerged from bug branch into latest mysql-5.5.
- Fixed trailing whitespaces.
- Updated the copyright notice year to 2014.
Bug#17081415:>=4GB ROW EVENT CRASHES SERVER WITH WILD MEMCPY
OF ROW DATA

Problem:
========
Inserting a row larger than 4G when server uses RBR leads
to crash.

Analysis:
========
Row-based binary logging logs changes in individual table
rows. During the execution of DML statements in RBR the
actual row data will be stored within "m_rows_buf" buffer
and this buffer contents will be written to binary log.
"m_rows_buf" is prepared within the following function
"Rows_log_event::do_add_row_data".

When a huge row is specified as in this bug scenario where
row size is 4294971520 > UINT_MAX (4294967295) then the
"m_rows_buf" is reallocated to accommodate the row data and
then the row is copied to the buffer. During this realloc
call, the length is getting type casted to "uint" which
results in overflow. Because of the overflow the reallocated
memory happens to be incorrect than what was requested
and it results in a crash during copy of rowdata to buffer.

Hence rows of size > 4GB cannot be written to binary log.
By default the event_length can be stored within 4 bytes
which in turn restricts an event's size to grow. Hence large
rows cannot be replicated using row based replication.

Fix:
===
An error is generated if the row size exceeds 4GB value.
Bug #17760379 COLLATIONS WITH CONTRACTIONS BUFFER-OVERFLOW THEMSELVES IN THE FOOT

Description: A typo in create_tailoring() causes the "contraction_flags" to be written
into cs->contractions in the wrong place. This causes two problems:
(1) Anyone relying on `contraction_flags` to decide "could this character be
part of a contraction" is 100% broken.
(2) Anyone relying on `contractions` to determine the weight of a contraction
is mostly broken

Analysis: When we are preparing the contraction in create_tailoring(), we are corrupting the 
cs->contractions memory location which is supposed to store the weights(8k) + contraction information(256 bytes). We started storing the contraction information after the 4k location. This is because of logic flaw in the code.

Fix: When we create the contractions, we need to calculate the contraction with (char*) (cs->contractions + 0x40*0x40) from ((char*) cs->contractions) + 0x40*0x40. This makes the "cs->contractions" to move to 8k bytes and stores the contraction information from there. Similarly when we are calculating it for like range queries we need to calculate it from the 8k bytes onwards, this can be done by changing the logic to (const char*) (cs->contractions + 0x40*0x40). And for ucs2 charsets we need to modify the my_cs_can_be_contraction_head() and my_cs_can_be_contraction_tail() to point to 8k+ locations.
BUG#18054998 - BACKPORT FIX FOR BUG#11765785 to 5.5

This is a backport of the patch of bug#11765785. Commit message
by Prabakaran Thirumalai from bug#11765785 is reproduced below:
Description:
------------
Global Query ID (global_query_id ) is not incremented for PING and 
statistics command. These two query types are filtered before 
incrementing the global query id. This causes race condition and 
results in duplicate query id for different queries originating from 
different connections.
      
Analysis:
---------
sqlparse.cc::dispath_command() is the only place in code which sets 
thd->query_ id to global_query_id and then increments it based on the 
query type. In all other places it is incremented first and then 
assigned to thd->query_id.
      
This is done such that global_query_id is not incremented for PING 
and statistics commands in dispatch_command() function.
      
Fix:
----
As per suggestion from Serg, "There is no reason to skip query_id for 
the PING and STATISTICS command.", removing the check which filters 
PING and statistics commands.
      
Instead of using get_query_id() and next_query_id() which can still 
cause race condition if context switch happens soon after executing 
get_query_id(), changing the code to use next_query_id() instead of 
get_query_id() as it is done in other parts of code which deals with 
global_query_id.
      
Removed get_query_id() function and forced next_query_id() caller 
to use the return value by specifying warn_unused_result attribute.
Bug#16316074 RFE: MAKE TMPDIR A BUILD-TIME CONFIGURABLE OPTION
Bug#68338    RFE: make tmpdir a build-time configurable option

Post-push fix: 'cmake -LH | grep TMP' showed TMPDIR as a BOOL option,
which was a bit confusing: show it as a PATH instead.
Bug#16316074 RFE: MAKE TMPDIR A BUILD-TIME CONFIGURABLE OPTION
Bug#68338    RFE: make tmpdir a build-time configurable option

Post-push fix: windows needs DEFAULT_TMPDIR as well.
Backport of Bug#16809055 MYSQL 5.6 AND 5.7 STILL USE LIBMYSQLCLIENT.SO.18
Backported only the softlink part of the patch,
*not* the bumping of library version.

With this patch, the libmysql/ directory contains:
libmysqlclient.a
libmysqlclient_r.a -> libmysqlclient.a
libmysqlclient_r.so -> libmysqlclient.so*
libmysqlclient_r.so.18 -> libmysqlclient.so.18*
libmysqlclient_r.so.18.0.0 -> libmysqlclient.so.18.0.0*
libmysqlclient.so -> libmysqlclient.so.18*
libmysqlclient.so.18 -> libmysqlclient.so.18.0.0*
libmysqlclient.so.18.0.0*
BUG 18117322 - DEFINE INNODB_THREAD_SLEEP_DELAY MAX VALUE

The maximum value for innodb_thread_sleep_delay is 4294967295 (32-bit) or
18446744073709551615 (64-bit) microseconds. This is way too big, since
the max value of innodb_thread_sleep_delay is limited by
innodb_adaptive_max_sleep_delay if that value is set to non-zero value
(its default is 150,000).

Solution
The maximum value of innodb_thread_sleep_delay should be the same as
the maximum value of innodb_adaptive_max_sleep_delay, which is 1000000.

Approved by Jimmy, rb#4429
Bug #14668683 ASSERT REC_GET_DELETED_FLAG(REC, PAGE_IS_COMP(PAGE))

Problem:

The function row_upd_changes_ord_field_binary() is used to decide whether to
use row_upd_clust_rec_by_insert() or row_upd_clust_rec().  The function
row_upd_changes_ord_field_binary() does not make use of charset information.
Based on binary comparison it decides that r1 and r2 differ in their ordering
fields.

In the function row_upd_clust_rec_by_insert(), an update is done by delete +
insert.  These operations internally make use of cmp_dtuple_rec_with_match()
to compare records r1 and r2.  This comparison takes place with the use of
charset information.

This means that it is possible for the deleted record to be reused in the
subsequent insert.  In the given scenario, the characters 'a' and 'A' are
considered equal in the my_charset_latin1.  When this happens, the ownership
information of externally stored blobs are not correctly handled.

Solution:

When an update is done by delete followed by insert, disown the relevant
externally stored fields during the delete marking itself (within the same
mtr).  If the insert succeeds, then nothing with respect to blob ownership
needs to be done.  If the insert fails, then the disown done earlier will be
removed when the operation is rolled back.

rb#4479 approved by Marko.
Bug#16814264: FILTER OUT THE PERFORMANCE_SCHEMA RELAY LOG EVENTS FROM RELAY LOG

  Performance schema tables are local to a server and they should not
  be allowed to be executed by the slave from the relay log.
  From 5.6.10, P_S events are not written into the binary log.
  But prior to that, from mysql 5.5 onwards, P_S events are written 
  to the binary log by master.
  The following are problematic scenarios:
      
  1. Master 5.5 -> Slave 5.5
     ========================
    A) RBR: Slave crashes
    B) SBR: P_S statements are replicated.
      
  2.Master 5.5 -> Slave 5.6
    ========================
    A) RBR: SQL thd generates error
    B) SBR : P_S statements are replicated
      
  3. 5.5 binlog executed on a server 5.5 using mysqlbinlog|mysql
     =================================================================
     A) RBR: Server crash  (because of BINLOG'... statement)
     B) SBR: P_S statements are executed
      
  4. 5.5 binlog executed on server 5.6 using mysqlbinlog|mysql
     ================================================================
     A) RBR: SQL error (because of BINLOG'... statement)
     B) SBR: P_S statements are executed.
      
      
    The generalized behaviour should be:
    a) Slave SQL thread should certainly ignore P_S events read from
       the relay log.
    b) mysqlbinlog|mysql should replay the binlog succesfully.
Bug#14117012 - CHILD PROCESS MYSQL UTILITIES PICKING UP LOCAL
               CONFIG FILES CAUSES TEST

Utility as "mysql_upgrade" forks "mysql"/"mysqlcheck". Attaching
"mysql_upgrade" shows following calls after forking "mysql" or
"mysql_check" when configuration file information is passed as
first argument to "mysql_upgrade".

strace -f ./mysql_upgrade --defaults-file=../pdb/my.cnf --socket=../pdb/mysql.sock -f

[pid  6254] stat("/etc/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
[pid  6254] stat("/etc/mysql/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
[pid  6254] stat("/usr/local/mysql/etc/my.cnf", 0x7fff8e772680) = -1 ENOENT (No such file or directory)
[pid  6254] stat("/home/user_name/.my.cnf", {st_mode=S_IFREG|0664, st_size=19, ...}) = 0
[pid  6254] open("/home/user_name/.my.cnf", O_RDONLY) = 3


But when tool forks "mysqlcheck"/"mysql", "--no-defaults" is passed
as first argument. Before forking, in function "find_tool" of
"mysql_upgrade", check is made to verify whether tool can be
executable or not by calling "mysqlcheck --help" and "mysql --help".
But argument "--no-defaults", "--defaults-file" or
"defaults-extra-file" is not passed to "mysql" and "mysqlcheck".
So my.cnf is searched in default paths.

Fix:
------
Modified code to pass "--no-defaults" as first argument to "mysql"
and "mysqlcheck" while checking tool can be executed or not.