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


sql/filesort.cc:
  Now we call unlock_row only if there is no
  previous error.

No commit message

                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 ]

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.

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.

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.

                LOCAL TABLE WHEN ONLY 1 LOCAL ROW

Description: When updating a federated table with UPDATE...
JOIN, the server consistently crashes with Signal 11 when
only 1 row exists in the local table involved in the join 
and that 1 row can be joined with a row in the federated 
table.

Analysis: Interaction between the federated engine and the
optimizer results in the crash. In our scenario, ie, local
table having only one row, the program is following a 
different path because the table is treated as a constant
table by the join optimizer. So in this scenario 
"index_read()" is happening in the prepare phase,
since optimizer plan is different for constant table joins.
In this case, "index_read_idx_map()" (inside handler.cc) is
calling "index_read()" and inside "index_read()", matching 
rows are fetched and "stored_result" gets populated by 
calling "store_result()". And just after "index_read()", 
"index_end()" function is called. And in the "index_end()",
its freeing the "stored_result" by calling "free_result()".
So when it reaches the execution phase, in "position()" 
function, we are getting assertion at 
"DBUG_ASSERT(stored_result);". In all other scenarios (ie, 
table with more than 1 row), optimizer plan is different 
and "index_read()" is happening in the execution phase.

Fix: So my fix is to have a separate ha_federated member
function for "index_read_idx_map()" which will handle 
federated engine separately. So that position() will be 
called before index_end() call in constant table scenario.

             ERRORS IN THE FK SECTION

ANALYSIS
--------

Any error during the renaming of the table was 
incorrectly logged in the dict_foreign_err_file
and it showed up in foreign key section when
we give the query "show engine innodb status".

FIX
---
Prevent renaming error from being logged in 
dict_foreign_err_file section.  

[Aprooved by marko #rb 2501 ]

               IT IS DONE IN-PLACE

Add testcase as innodb-change-buffer-recovery.test

      
Adding the test cases for the BUG#16451878.

                              FAILS TO DROP CREATED EVENTS:

- Check for triggers should exclude mtr's own
- Move the code to before checksum table as it might affect result
  of some autdit_log tests (does in 5.6)
- Replace SHOW STATUS LIKE 'slave_open_temp_tables' to be like in 5.6

fix: DROP EVENT e1;

Bug#68338    RFE: make tmpdir a build-time configurable option

Background: Some distributions use tmpfs for mounting /tmp by
default, which has some advantages, but brings also new
issues. Fedora started using tmpfs on /tmp in version 18 for
example. If not configured otherwise in my.cnf, MySQL uses
system's constant P_tmpdir expanded to /tmp on Linux. This can
introduce some problems with limited space in /tmp and also some
data loss in case of replication slave [1].

In case distributions would like to use /var/tmp, which should be
better for MySQL purposes, then we have to patch the source or
change tmpdir option in my.cnf, which is however not updated in
case it has already existed.

Thus, it would be useful to be able to specify default tmpdir
path using a configure option, while using P_tmpdir in case it is
not defined explicitly.

Based on a contribution from Honza Horak

(MYSQLBINLOG -V CRASHES WITH THAT BINLOG)

Post Push: Fixing Werror compiler issue 

(MYSQLBINLOG -V CRASHES WITH THAT BINLOG)

Problem: If slave receives a corrupted row event,
slave server is crashing.

Analysis: When slave is unpacking the row event, it is
not validating the data before applying the event. If the
data is corrupted for eg: the length of a field is wrong,
it could end up reading wrong data leading to a crash.
A similar problem happens when mysqlbinlog tool is used
against a corrupted binlog using '-v' option. Due to -v
option, the tool tries to print the values of all the
fields. Corrupted field length could lead to a crash.

Fix: Before unpacking the field, a verification
will be made on the length. If it falls into the event
range, only then it will be unpacked. Otherwise,
"ER_SLAVE_CORRUPT_EVENT" error will be thrown.
Incase mysqlbinlog -v case, the field value will not be
printed and the processing of the file will be stopped.

sql/field.h:
  Removed a function which is not required anymore
sql/log_event.cc:
  Adding a validation on the field length before
  the tool tries to print the value.
sql/log_event.h:
  Changing unpack_row call according to the new arguments
sql/log_event_old.h:
  Changing unpack_row call according to the new arguments
sql/rpl_record.cc:
  Adding a new argument 'row_end' which tells
  the end position of the complete data in the
  row event. It will be used to do validation
  before doing 'unpack' field.
sql/rpl_record.h:
  Adding a new argument 'row_end' which tells
  the end position of the complete data in the
  row event. It will be used to do validation
  before doing 'unpack' field.
sql/rpl_utility.cc:
  Now calc_field_size() is required for client too.

Bug#29716 : Bug#11746921 : MYSQL_INSTALL_DB REFERS TO THE (OBSOLETE) MYSQLBUG SCRIPT DURING INSTALLATION
Bug#68742 : Bug#16530527 : OBSOLETE BUGREPORT ADDRESSES

DESTRUCTED THD OBJ 

Prior to fix, function check_performance_schema() could leave
behind stale pointers in thread local storage, for the following keys:
- THR_THD (used by _current_thd)
- THR_MALLOC (used for memory allocation)
This is an unsafe practice, which can potentially cause crashes,
and that can cause other bugs when code is modified during maintenance.

With this fix, thread local storage keys used temporarily within
function check_performance_schema() are cleaned up after use.

Bug#17867117 - ERROR RESULT WHEN "COUNT + DISTINCT + CASE WHEN" NEED MERGE_WALK 

Problem:
COUNT DISTINCT gives incorrect result when it uses a Unique
Tree and its last inserted record has null value.

Here is how COUNT DISTINCT is processed, given that this query is not
using loose index scan.

When a row is produced as a result of joining tables (there is only
one table here), we store the SELECTed value in a Unique tree. This
allows elimination of any duplicates, and thus implements DISTINCT.

When we have processed all rows like this, we walk the Unique tree,
counting its elements, in Aggregator_distinct::endup() (tree->walk());
for each element we call Item_sum_count::add(). Such function wants to
ignore any NULL value, for that it checks item_sum -> args[0] ->
null_value. It is a mistake: when walking the Unique tree, the value
to be aggregated is not item_sum ->args[0] but rather table ->
field[0].

Solution:
instead of item_sum -> args[0] -> null_value, use arg_is_null(), which
knows where to look (like in fix for bug 57932).

As a consequence of this solution, we have to make arg_is_null() a
little more general:
1) Because it was so far only used for AVG() (which always has a
single argument), this function was looking at a single argument; now
that it has to work with COUNT(DISTINCT expression1,expression2), it
must look at all arguments.
2) Because we start using arg_is_null () for COUNT(DISTINCT), i.e. in
Item_sum_count::add (), it implies that we are also using it for
COUNT(no DISTINCT) (same add ()). For COUNT(no DISTINCT), the
nullness to check is that of item_sum -> args[0]. But the null_value
of such item is reliable only if val_*() has been called on it. So far
arg_is_null() was always used after a call to arg_val*(), so could
rely on null_value; but for COUNT, there is no call to arg_val*(), so
arg_is_null() has to call is_null() instead.

Testcase for 16539979 by Neeraj. Testcase for 17867117 contributed by
Xiaobin Lin from Taobao.

Fix :
-------	

Created separate suites called innodb_zip ans i_innodb_zip that contain all compression tests.

Running the new suites with following compression-related parameters :

* innodb_compression_level = {1/9}
* innodb_log_compressed_pages = {ON/OFF}

No commit message

MALFORMED XPATH EXP
Problem:
A malformed XPATH expression in the ExtractValue query is causing
a server crash. This malformed XPATH expression is resulted when 
the position attribute in the substring function contains ".." in
the beginning.
Solution:
The original crash is happening because the "../" is being evaluated
prematurely. It tries to access XML while it hasn't been parsed yet.
The premature evaluation is happening because the val_nodeset function
is being set to constant, in which case we proceed to evaluate them in
JOIN:prepare stage only. The solution to this is setting the val_nodeset
functions as non-constant. This forces us to evaluate the function in
the JOIN:exec stage and thus avoid any premature evaluation of the 
XML strings.

WITH MALFORMED XPATH EXP
Problem:
A malformed XPATH expression in the ExtractValue query is 
causing a server crash. This malformed XPATH expression is
resulted when the position attribute in the substring function
contains ".." in the beginning.
Solution:
The original crash is happening because the "../" is being 
evaluated prematurely. It tries to access XML while it 
hasn't been parsed yet. The premature evaluation is happening
because the val_nodeset function is being set to constant, 
in which case we proceed to evaluate them in JOIN:prepare
stage only. The solution to this is setting the val_nodeset
functions as non-constant. This forces us to evaluate the function
 in the JOIN:exec stage and thus avoid any premature evaluation of
the XML strings.

              SPECIFIED WITH THE BASEDIR OPTION 

Description: The mysql_plugin client attempts to remove any
filename specified to the --basedir option. The problem is
that if the filename does not end with a slash, it will 
attempt to unlink it, which succeeds for files, but not for
directories.

Analysis: When we are starting mysql_plugin with basedir 
option and if we are giving path of a file as basedir, it 
deletes that file. It was because it uses a function 
my_delete which unlinks the file path given.

Fix:  As a fix we replace that line using another function 
my_free, which will only free the  pointer which is having 
that file path.

revid:mattias.jonsson@oracle.com-20131119103616-u6t82s8cpgp0q3ex

Use of uninitialized memory in the priority queue used for returning records
in sorted order.

It happens if no previous partition have returned a row since the
beginning of index_init + an index_read* call returned
HA_ERR_KEY_NOT_FOUND for all partitions (otherwise the record
buffer/priority queue would be initialized) + an index_next/prev
call where all partitions returns HA_ERR_END_OF_FILE.

                WITH SORT ABORTED LEAKS FILE DESCRIPTORS

ISSUE : IO_CACHE used for index_merge quick select
is freed only on successful retrieval of all rows
from index merge.
Suppose if there is a interrupt( or failure) to
this operation of row retrieval (let it be a
KILL_QUERY signal) then we are not freeing the IO_CACHE
resources allocated by index_merge quick select.
And hence temp file associated with it is also not closed.
This lead to a file descriptor leak.

SOLUTION : As part of file sort operation now we always 
free the IO_CACHE allocated by index_merge quick select.

sql/filesort.cc:
  In filesort function we try to free if any
  IO_CACHE allocated by index_merge quick select
  and if it is not yet freed.

No commit message

Problem: The "--local-install" service does not perform as expected for, at least,
         Windows.

Fix: A NULL pointer was dereferenced due to which there was crash.A check was introduced
     for NULL string before dereferencing it.No test cases written as it is a bug during 
     installation.

Problem:
When log_warnings is greater than 1, master prints binlog
dump thread information in mysqld.1.err file.
The information contains slave server id, binlog file and
binlog position. The slave server id is uint32 and the print
format was wrongly specifified (%d instead of %u).
Hence a server id which is more than 2 billion is getting
printed with a negative value.
Eg: Start binlog_dump to slave_server(-1340259414),
pos(mysql-bin.001663, 325187493)

Fix: Changed the uint32 format to %u.

                RESULTING MY_WC_T RESULT IS NOT USED
Issue         : handler functions my_ismbchar_utf8,
              my_well_formed_len_mb for charset utf8
              is calling unicode converion function
              to validate and to find the character
              length. Because of this, instructions
              which will convert the utf8 to unicode
              are executed for no use.
              A similar issue exist with charset utf8mb4
Solution      : reorganized the code such that character
              validation part of unicode conversion
              handler is extracted(duplicated) in to
              separate function. Hence
              my_ismbchar_utf8, my_well_formed_len_mb
              will call the new function which only
              validates and return the length of mb(utf8).
              A similar fix for charset utf8mb4.

strings/ctype-utf8.c:
  New functions has been added for charset utf8 and utf8mb4
  to validate and to get the length of the character.

Fix Windows build break