Problem - When the slave was disconnected from the master, under certain 
          conditions, upon reconnect, it will report that it received a 
          packet larger the slave_max_allowed_packet which causes the
          replication to stop.
 
Analysis -The reason of this failure is that on reconnect
          the slave sets the max_allowed_packet from the master's mi->mysql
          object which keeps the max_allowed_packet as 1MB. This causes the 
          slave to report such error on recieving packet bigger than 1MB. 
          START SLAVE on the slave fixes the problem since it restarts
          slave threads which initializes the max_allowed_packet to
          slave_max_allowed_packet.
      
Fix - The problem is fixed by some code refactoring and introduction of a new
      function which updates the max_allowed_packet for the THD object of the
      slave thread and the mysql->options max_allowed_packet.

As current size limit of 'url' field of help_topic
table is no longer sufficient for the contents of
the fill_help_tables-5.1.sql. So, loading the contents
in the table might result in warning (or error with
stricter modes).

Updated the type for 'url' field of help_topic as well
as help_category tables from char(128) to text.

(Based on Sinisa's patch)

Added a version checking facility to mysql_upgrade.
The versions used for checking is the version of the
server that mysql_upgrade is going to upgrade and the
server version that mysql_upgrade was build/distributed
with.
Also added an option '--version-check' to enable/disable
the version checking.

SHOW ENGINE INNOD

Problem:

The purpose of explain_filename() is to provide useful additional
information regarding the partitions given the filename.  This function
was returning an error when it was not able to parse the given filename.
For example, within InnoDB, temporary files are created with #sql-
prefix.  But this function was not able to parse it correctly.

Solution:

It is not an error, if explain_filename() could not parse the given
filename.  If there is no partition information to explain, then silently
return from the function.

rb#1940 approved by mattiasj

The range optimizer uses 'save_in_field_no_warnings()' to verify properties of
'value <cmp> field' expressions.
If this execution yields an error, it should abort.

              RETURNS RANDOM DATA
                 
MySQL 5.5 specific version of bugfix.
      
When Loose Index Scan Range access is used, MySQL execution needs
to copy non-aggregated fields. end_send() checked if this was
necessary by checking if join_tab->select->quick had type
QS_TYPE_GROUP_MIN_MAX.
      
In this bug, however, MySQL created a sort index to sort the rows
read from this range access method. create_sort_index() deletes
join_tab->select->quick which makes it impossible to inquire
the join_tab if LIS has been used.
      
The fix for MySQL 5.5 is to introduce a variable in JOIN_TAB
that stores whether or not LIS has been used. There is no need
for this variable in later MySQL versions because the relevant
code has been refactored.

Post push fix:
setup_ref_array() now uses n_sum_items to determine size of ref_pointer_array.
The problem was that n_sum_items kept growing, it wasn't reset for each query.

A similar memory leak was fixed with the patch for:
Bug 14683676 ENDLESS MEMORY CONSUMPTION IN SETUP_REF_ARRAY WITH MAX IN SUBQUERY

UPDATES

After checking that the table has changed too much in
row_update_statistics_if_needed() and calling dict_update_statistics(),
also check if the same condition holds after acquiring the table stats
latch. This is to avoid multiple threads concurrently entering and
executing the stats update code.

Approved by:	Marko (rb:2186)

Problem:
=======
Found using AddressSanitizer testing.

The mysqlbinlog utility may result in out-of-bound heap
buffer reads and thus, undefined behaviour, when processing
RBR events in the old (pre-5.1 GA) format.

The following code in process_event() would only be correct
if Rows_log_event was the base class for
Write,Update,Delete_rows_log_event_old classes:

    case PRE_GA_WRITE_ROWS_EVENT:
    case PRE_GA_DELETE_ROWS_EVENT:
    case PRE_GA_UPDATE_ROWS_EVENT:
...
        Rows_log_event *e= (Rows_log_event*) ev;
        Table_map_log_event *ignored_map=
          print_event_info->m_table_map_ignored.get_table(e->get_table_id());
...
        if (e->get_flags(Rows_log_event::STMT_END_F))
        {
...
        }

However, Rows_log_event is only the base class for the
Write,Update_Delete_rows_event family of classes, but not
for their *_old counterparts. So the above typecasts are
incorrect for the old-format RBR events and may result (and
do result according to AddressSanitizer reports) in reading
memory outside of the previously allocated on heap buffer.

Fix:
===
The above mentioned invalid type cast has been replaced with
appropriate old counterpart.

Note:The above mentioned issue is present only mysql-5.1 and
5.5. This is fixed in mysql-5.6 and above as part of 
Bug#55790. Hence few of the relevant changes of Bug#55790 are
being back ported to fix the current issue.

	
	Backport the changes for bug#14786792 which is regression 
	of fix for bug#11761854.So backported both changes.

  INTERACTIVE MODE

In interactive mode, libedit/readline allocates memory
for every new line entered & later the allocated memory
never gets freed.

Fixed by freeing the allocated memory blocks appropriately.

Null merge from mysql-5.1

Back porting fix from mysql-5.5

We need to take 'n_sum_items' into the calculation
when allocating the ref_ptr_array.

Item_func_group_concat::copy_or_same() creates a copy of original object.
It also creates a copy of ORDER structure because ORDER struct elements may
be modified in find_order_in_list() called from Item_func_group_concat::setup().
As ORDER copy is created using memcpy, ORDER::next elements point to original
ORDER structs. Thus find_order_in_list() called from EXECUTE stmt modifies
ordinal ORDER item pointers so they point to runtime items, these items are
freed after execution, so original ORDER structure becomes invalid.
The fix is to properly update ORDER::next fields so that they point to
new ORDER elements.

COLUMNS ARE USED INSIDE A STORED PROCEDURE 
Merging post-push fix from mysql-5.1

COLUMNS ARE USED INSIDE A STORED PROCEDURE

Post-push fix.
String::operator=() in client/sql_string.h also 
needs to be updated with fix.

             FREED LOCK

ANALYIS
-------

In 5.5 code the lock_rec_block_validate() is called after releasing
the kernel mutex. There is a chance that the lock might be invalid so,
we are getting the valgrind error on invalid read on lock->index.

FIX
---

Fix would be to copy the lock->index when we are holding the kernel mutex 
and then pass it to the lock_rec_block_validate(). This implementation
is present in 5.1 code.  

[ Approved by sunny rb.no.oracle.com/rb/r/2152/ ]

Description: Null merge from 5.1.

No commit message

COLUMNS ARE USED INSIDE A STORED PROCEDURE                                      
                                                                                
Problem: When 'SET' type columns are used in a DML                              
inside a stored procedure and a NULL value is passed                            
to that column, replication is breaking.                                        
                                                                                
Analysis: All stored procedure variables used inside                            
a DML will be substituted with NAME_CONST functions.                            
While NAME_CONST are used in this particular scenario,                          
i.e., when NULL value is passed then charset is copied                          
from 'empty_set_string' member of Field_set class.                              
The operator '=' overload method inside 'String' class                          
is not coping str_charset from R.H.S object to L.H.S object.                    
Hence charset is wrongly copied in the string assignment                        
                                                                                
Fix: Handle coping str_charset member in operator '=' overload                  
method.

COLUMNS ARE USED INSIDE A STORED PROCEDURE                                      
                                                                                
Problem: The operator '=' overload method inside
'String' class is not coping str_charset member from
R.H.S object to L.H.S object. Hence charset is wrongly
set while using string assignments

Analaysis: The above mentioned problem is
identified while doing the analaysis of bug#14593883.
Though the test scenario mentioned in the bug page
is not  an issue in mysql-5.1 code, the actual root cause
ie., "str_charset member is not copied" exists in the 
mysql-5.1 code base. 

Fix: Handle coping str_charset member in operator '=' overload                  
method.