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

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

No commit message

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 ]   

ON DELETION ORDER

Problem:

When a InnoDB index page is under-filled, we will merge it with either
the left sibling node or the right sibling node.  But this checking is
incorrect.  When the left sibling node is available, even if merging
is not possible with left sibling node, we do not check for the 
possibility of merging with the right sibling node.  

Solution:

If left sibling node is available, and merging with left sibling node
is not possible, then check if merge with right sibling node is
possible.

rb#2506 approved by jimmy & ima.

CAN LEAD TO MISSING TABLES

Overview
--------
If the FOREIGN_KEY_CHECKS system variable is set to 0, it is
possible to break a foreign key constraint by changing the type
or character set of the foreign key column, or by dropping the
foreign key index (without carrying out corresponding changes on
another table in the relationship).

If we subsequently set FOREIGN_KEY_CHECKS to 1 and execute ALTER
TABLE involving the COPY algorithm on such a table, the following
happens:

1) If ALTER TABLE does not contain a RENAME clause, the attempt 
   to install the new version of the table instead of the old one
   will fail due to the fact that the inconsistency will be 
   detected. An attempt to revert the partially executed alter 
   table operation by restoring the old table definition will 
   fail as well due to FOREIGN_KEY_CHECKS == 1. As a result, the 
   table being altered will be lost.
2) If ALTER TABLE contains the RENAME clause, the inconsistency 
   will not be detected (most probably due to other bugs). But if
   an attempt to install the new version of the table fails (for 
   example, due to a failure when updating triggers associated 
   with the table), reverting the partially executed alter table 
   by restoring the old table definition will fail too. So the 
   table being altered might be lost as well.


Suggested fix
-------------
The suggested fix is to temporarily unset the option bit
representing FOREIGN_KEY_CHECKS when the old table definition is
restored while reverting the partially executed operation.

No commit message

Revert fix since it caused mtr tests to not run in pushbuild.

      Bug#13116514 - CREATE LOGFILE GROUP INITIAL_SIZE & UNDO_BUFFER_SIZE FAILS
      
      Fixing parser to accept the syntax: to give a size with suffix 'M', eg. undo_buffer_size=10M (M for mega bytes), in 'create logfile group' command.

i_s_innodb_buffer_page_get_info(): Do not read the buffer block frame
contents of read-fixed blocks, because it may be invalid or
uninitialized. When we are going to decompress or read a block, we
will put it into buf_pool->page_hash and buf_pool->LRU, read-fix the
block and release the mutexes for the duration of the reading or
decompression.

rb#2500 approved by Jimmy Yang

BY BINLOG_KILLED_SIMULATE.TEST
Merging fix from mysql-5.1

BY BINLOG_KILLED_SIMULATE.TEST
      
'mysqbinlog' tool creates a temporary file while 
preparing LOAD DATA QUERY. These files needs to be deleted
at the end of the test script otherwise these files are
left out in the daily-run machines, causing
"no space on device issues"
      
Fix: 
Delete them at the end of these test scripts
1) execute mysqlbinlog with --local-load option to
create these files in a specified tmpdir
2) delete the tmpdir at the end of the test script

                                 STRING CONVERSION FUNCTIONS
            
Problem:
While executing the prepared statement, user variable is
set to memory which would be freed at the end of
execution.
If the statement is executed again, valgrind throws
error when accessing this pointer.
                  
Analysis:
                
1. First time when Item_func_set_user_var::check is called,
   memory is allocated for "value" to store the result.
   (In the call to copy_if_not_alloced).
2. While sending the result, Item_func_set_user_var::check
   is called again. But, this time, its called with
   "use_result_field" set to true. 
   As a result, we call result_field->val_str(&value).
3. Here memory allocated for "value" gets freed. And "value"
   gets set to "result_field", with "str_length" being that of
   result_field's.
4. In the call to JOIN::cleanup, result_field's memory gets
   freed as this is allocated in a chunk as part of the
   temporary table which is needed to execute the query.
5. Next time, when execute of the same statement is called,
   "value" will be set to memory which is already freed.
   Valgrind error occurs as "str_length" is positive 
   (set at Step 3)
                  
Note that user variables list is stored as part of the Lex object
in set_var_list. Hence the persistance across executions.
            
Solution:
Patch for Bug#11764371 fixed in mysql-5.6+ fixes this problem 
as well.So backporting the same.
            
In the solution for Bug#11764371, we create another object of 
user_var and repoint it to temp_table's field. As a result while 
deleting the alloced buffer in Step 3, since the cloned object 
does not own the buffer, deletion will not happen.
So at step 5 when we execute the statement second time, the 
original object will be used and since deletion did not happen 
valgrind will not complain about dangling pointer.

Bug#12608543: CRASHES WITH DECIMALS AND STATEMENT NEEDS TO BE REPREPARED ERRORS

Backporting these two fixes to 5.1 
Added unittest to test my_decimal construtor and assignment operators

No commit message

              USING THE PLUGIN INTERFACE.

ISSUE: No support for floating-point plugin
       system variables.

SOLUTION: Allowing plugins to define and expose floating-point
          system variables of type double. MYSQL_SYSVAR_DOUBLE
          and MYSQL_THDVAR_DOUBLE are added.

ISSUE: Fractional part of the def, min, max values of system
       variables are ignored.

SOLUTION: Adding functions that are used to store the raw
          representation of a double in the raw bits of unsigned
          longlong in a way that the binary representation
          remains the same.

ESCAPED WITH BACKSLASH

Problem:

When the CREATE TABLE statement used COMMENTS with escape sequences like
'foo\'s', InnoDB did not parse is correctly when trying to extract the
foreign key information.  Because of this, the foreign keys specified
in the CREATE TABLE statement were not created.

Solution:

Make the InnoDB internal parser aware of escape sequences. 

rb#2457 approved by Kevin.

MYSQL DB FROM REMOTE 5.0.96 SERVER

Problem: mysqldump tool assumes the existence of
general_log and slow_log tables in the server.
If mysqldump tool executes on a old server where
there are no log tables like these, mysqldump tool
fails.

Analysis: general_log and slow_log tables are added
in the ignore-table list as part of bug-26121 fix
causes bug-45740 (MYSQLDUMP DOESN'T DUMP GENERAL_LOG
AND SLOW_QUERY CAUSES RESTORE PROBLEM). As part of
the bug-45740 fix, mysqldump tool adds create table
queries for these two tables. But the fix assumes
that on all the servers, general_log and slow_log
will be there. If the new mysqldump tool is executed
against a old server where there are no general_log
and slow_log, the mysqldump tool fails with an error
that 'there is no general_log table'.

Fix: When mysqldump tool is trying to retrieve general_log
and slow_log table structures, first the tool should
check their existence of these tables in the server
instead of trying to dump it blindly.

No commit message

which is supported only for MYSQL server versions 5.6 and above.

The problem was in get_partition_id_cols_range_for_endpoint
and cmp_rec_and_tuple_prune, which stepped one partition too long.

Solution was to move a small portion of logic to cmp_rec_and_tuple_prune,
to simplify both get_partition_id_cols_range_for_endpoint and
get_partition_id_cols_list_for_endpoint.

ibuf_insert_to_index_page_low() add a DBUG_RETURN(NULL).