commit 933465dc2c781fafb7d56511cf91cb6c54fe3d6c
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Mon May 16 13:47:58 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6
    
    (cherry picked from commit d8de93d8853fce9246c5ada4de4b47b1f59b912e)

commit 70145f2d8b0eb0793c9255088e1e9b98af7bca3e
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Fri May 13 11:35:58 2016 +0530

    Bug#22669012: SERVER CRASH AT OPENSSL_CONFIG IF OPENSSL_UDF FUNCTION.
    
    Post push fix.
    
    (cherry picked from commit 58c739cb49869be45ab68348b962e3e37ceb1a97)

commit 6c298096aaae6badc1ba6bf87142edd25b30ffea
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri May 13 16:44:23 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6
    
    (cherry picked from commit 3c6c5aa14d0b0e4362e26ea8964c9a7a790e0802)

commit 28573a56b7f311a951e6c6d1ae460be220676fe5
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Thu May 12 15:05:21 2016 +0530

    BUG#23273818 - MARIADB-SERVER-GALERA NOT REPLACED WITH COMMUNITY PACKAGES DURING FC24 UPGRADE
    
        Add obsolete on mariadb-server-galera similar to mariadb-galera-server.
    
    (cherry picked from commit 0972c605629fd1ce350efb56a4ac8e537281a007)

commit ccad17c02e4db24fe7e9db113e835e4de00517a0
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Wed May 11 21:03:45 2016 +0530

    Bug #22669012:  SERVER CRASH AT OPENSSL_CONFIG.
    
    Post push fix.
    
    (cherry picked from commit 6532334b8c59976fad77ef2fb14cc7d635f240a4)

commit 35c28bee09ee92176ca1f841aa2bccd5cd508513
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Wed May 11 13:44:13 2016 +0530

    Bug #22669012: SERVER CRASH AT OPENSSL_CONFIG IF OPENSSL_UDF FUNCTION CREATED/DROPPED FROM MTR.
    
    (cherry picked from commit 8e83bb529ed741c38959c5783bdd43b7ca4a602d)

commit 27cc2a34b5e20d4e340a25d26de98edda63eab2a
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Thu May 5 19:05:10 2016 +0530

    Bug #23227804	MYSQL 5.6 DON'T BUILD ON FEDORA 24 WITH GCC 6
    
    a) Split each assert into individual assers when '&&' used.
    b) Change the assert or condition from var to var != NULL.
    c) Space between string and macro.
    d) To avoid left shift of negative value error,
    change (~0 << val) to (~0U << val).
    
    Reviewed-by: Naga Satyanarayana Bodapati <satya.bodapati@oracle.com>
    RB: 12600
    (cherry picked from commit 6ee186cee7f6411c33b88f1e5b9b9951c9eec699)

commit faf221e8ae7dbd699b9a916839545d640b971c5c
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Tue May 3 09:28:35 2016 +0200

    Added deb-xenial directory to packaging
    
    To support building on Ubuntu 16.04. Based on 15.10 packaging
    
    (cherry picked from commit bcfafb0da1bd1d4e63e6e66f6e9235f0e9f5da9f)

commit f6dc833e597726b37669981dd68d43438b99b7a3
Merge: 6fd38b4 bf4f206
Author: Harin Vadodaria <harin.vadodaria@oracle.com>
Date:   Fri Apr 29 12:42:16 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit bf4f206f697889a7ae068f7d21a4aeb6e6a7ec74
Author: Harin Vadodaria <harin.vadodaria@oracle.com>
Date:   Fri Apr 29 11:06:41 2016 +0530

    Bug#21973610
    
    Post push fix : Fixing i_main.mysqlshow failure.

commit 6fd38b488fdfb3e9e1626075f4671fa2f15571e2
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Apr 28 08:39:09 2016 +0530

    Bug #22305361: QUERY WITH MATERIALIZED TABLE RETURNS
                   INCORRECT RESULTS IN 5.6
    
    Issue
    -----
    This issue occurs with a query of the form
    SQ1 IN (SQ2 IN (SQ3)). To handle the first IN, a semijoin
    is used and the subquery is materialized. The second IN
    is converted to EXISTS optimization.
    
    During IN-TO-EXISTS transform for SQ3,
    Item_in_subselect's used_tables_cache is set to 3 instead
    of 2. This is because <left expr> is a direct_ref to
    concat(a,''). It visits Item_ref::resolved_used_tables.
    The used_tables_cache of concat(a,'') is set to 1. This
    difference allows for the condition to be eliminated by
    make_cond_for_table_from_pred, since the table, represented
    by used_tables_cache, is not referenced.
    
    
    SOLUTION:
    ---------
    This is the same problem fixed in Bug#21139722.
    
    The issue is solved by creating a new used_tables_for_level
    for Item_field class. This will return the table number if
    the column is resolved in the current query block. If it is
    resolved in an outer query block, the appropriate value is
    returned.
    
    Since constant tables are not handled in
    Item_field::used_tables_for_level, Bug#21139402 is also
    backported.

commit ac18af362dd7e26494c91300cc8bc627d2b652b1
Merge: e7899d1 d36cd34
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Wed Apr 27 14:23:51 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit e7899d1394c6d41d4bf3a0872d0769a787630a5a
Author: Aditya A <aditya.a@oracle.com>
Date:   Mon Apr 25 21:31:56 2016 +0530

    Bug #21133329	HANGING "SYSTEM LOCK" WHEN EXECUTING "FLUSH TABLE ... FOR EXPORT"
    
    Post push failure fix for compilation error in some platforms

commit 4e714b247fdce35a3058a180b3f3fb47a86f20c1
Author: Aditya A <aditya.a@oracle.com>
Date:   Mon Apr 25 12:37:46 2016 +0530

    Bug #21133329	HANGING "SYSTEM LOCK" WHEN EXECUTING "FLUSH TABLE ... FOR EXPORT"
    
    
    PROBLEM
    -------
    
    1. ibuf_contarct_in background() function is trying to merge
       all pages related to a certain table (which contains no record).
       while in background heavy DML operations are happening.
    2. When contracting the pages in ibuf_merge_space() we call
       ibuf_get_merge_pages() to get the pages to be merged.This function
       call returns the volume ( in bytes) of pages to be merged.
    3. In our case , the returned volume is zero since there are no pages
       to be merged ,but we increment the volume returned by 1 .
    4. This volume is returned to ibuf_contract_in_background() which
       assumes that some pages have been merged and doesn't break the loop
       It doesn't check if any pages have been merged but assumes that since
       volume is non zero some pages are merged and waits for it to reach
       sum_pages and gets stuck in this loop
    
    FIX
    ---
    
    1) The reason we increment the volume by 1 ,is because the function
       is supposed to return zero only if the ibuf tree is empty.
    2) To fix this we first have delinked the ibuf_merge_space() from the loop
       present in ibuf_contarct_in background() , it is independently called
       during quisec and returns number of pages merged instead of the size.
    3) Also as part of this fix we have backported Bug19724300 to make used of space_id
       instead of table id.
    
        Bug#19724300 REMOVE TABLE LOOKUPS FROM THE CHANGE BUFFER
    
        When exporting a tablespace, InnoDB needs to merge all buffered changes to
        that tablespace. However, the API for that is using the table_id, and we are
        performing unnecessary table lookups in the change buffer. The lookups should
        never fail (there is dead code), because MDL will be preventing a concurrent
        ALTER/TRUNCATE/DROP TABLE while the export operation is pending.
    
        ibuf_get_table(): Remove.
    
        ibuf_merge(): Replace table_id with space_id.
    
        ibuf_contract(): Call ibuf_merge_pages() directly.
    
        ibuf_merge_in_background(): Renamed from ibuf_contract_in_background().
        Replace table_id with space_id.
    
    [#rb12209 AND #rb6890  approved by jimmy ]

commit d36cd341d121bfd9a68f90fce6dfd2526fa9a8c8
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Fri Apr 22 10:25:16 2016 +0530

    BUG#23135731: INSERT WITH DUPLICATE KEY UPDATE REPORTS
                  INCORRECT ERROR.
    
    Analysis
    ========
    INSERT with DUPLICATE KEY UPDATE and REPLACE on a table
    where foreign key constraint is defined fails with an
    incorrect 'duplicate entry' error rather than foreign
    key constraint violation error.
    
    As part of the bug fix for BUG#22037930, a new flag
    'HA_CHECK_FK_ERROR' was added while checking for non fatal
    errors to manage FK errors based on the 'IGNORE' flag. For
    INSERT with DUPLICATE KEY UPDATE and REPLACE queries, the
    foreign key constraint violation error was marked as non-fatal,
    even though IGNORE was not set. Hence it continued with the
    duplicate key processing resulting in an incorrect error.
    
    Fix:
    ===
    Foreign key violation errors are treated as non fatal only when
    the IGNORE is not set in the above mentioned queries. Hence reports
    the appropriate foreign key violation error.

commit bd8d35520d2fc3d3d12e972d9667e59f0dadfa34
Merge: 1a88e27 9408ac7
Author: Karthik Kamath <karthik.kamath@oracle.com>
Date:   Tue Apr 19 14:51:54 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 9408ac7a301718182dbefb2fe122ae11e6e42c4c
Author: Karthik Kamath <karthik.kamath@oracle.com>
Date:   Tue Apr 19 14:49:27 2016 +0530

    BUG#22286421: NULL POINTER DEREFERENCE
    
    ANALYSIS:
    =========
    A LEX_STRING structure pointer is processed during the
    validation of a stored program name. During this processing,
    there is a possibility of null pointer dereference.
    
    FIX:
    ====
    check_routine_name() is invoked by the parser by supplying a
    non-empty string as the SP name. To avoid any potential calls
    to check_routine_name() with NULL value, a debug assert has
    been added to catch such cases.

commit 1a88e27ff4948ff71d6e30447c3f975e9ea39519
Merge: b655666 5bdafc8
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Tue Apr 19 11:47:21 2016 +0530

    Bug#22897202: RPL_IO_THD_WAIT_FOR_DISK_SPACE HAS OCCASIONAL
    FAILURES
    
    Merge branch 'mysql-5.5' into mysql-5.6

commit 5bdafc8efe1d2f7cf411e5705d90ac5668a88ca1
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Apr 11 11:41:47 2016 +0530

    Bug#22897202: RPL_IO_THD_WAIT_FOR_DISK_SPACE HAS OCCASIONAL
    FAILURES
    
    Analysis:
    =========
    Test script is not ensuring that "assert_grep.inc" should be
    called only after 'Disk is full' error is written to the
    error log.
    
    Test checks for "Queueing master event to the relay log"
    state. But this state is set before invoking 'queue_event'.
    Actual 'Disk is full' error happens at a very lower level.
    It can happen that we might even reset the debug point
    before even the actual disk full simulation occurs and the
    "Disk is full" message will never appear in the error log.
    
    In order to guarentee that we must have some mechanism where
    in after we write "Disk is full" error messge into the error
    log we must signal the test to execute SSS and then reset
    the debug point. So that test is deterministic.
    
    Fix:
    ===
    Added debug sync point to make script deterministic.

commit b655666361888699ef4a0a6901ebed87df13775b
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Mon Apr 18 12:39:36 2016 +0800

    Followup: BUG#22996488 - CRASH IN FTS_SYNC_INDEX WHEN DOING DDL IN A LOOP
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 12340

commit 441c2ddef5dc9cf908c0b0da6c71b9ca71213054
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Thu Apr 14 18:09:06 2016 +0800

    BUG#22996488 - CRASH IN FTS_SYNC_INDEX WHEN DOING DDL IN A LOOP
    
    Problem:
    The index cache has been freed by DROP INDEX when we are syncing
    a index cache in background.
    
    Solution:
    Acquire dict_operation_lock to prevent DDL like purge thread.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 12340

commit 6e120f9e2e121737af4cf19df9faf0b57bf4c337
Merge: fa986f1 7b2fa28
Author: Sreedhar.S <sreedhar.sreedhargadda@oracle.com>
Date:   Thu Apr 14 14:20:49 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 7b2fa28fedf715070e2dc9ed5a2a8a9dbe592cfb
Author: Sreedhar.S <sreedhar.sreedhargadda@oracle.com>
Date:   Thu Apr 14 14:18:23 2016 +0530

    Fix for Bugs#14583183 and 19949163

commit fa986f1f8bc8d4d46a843c4ae7d01cf44aa04edf
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Apr 13 11:14:56 2016 +0530

    Bug#22578574: MEMORY LEAK FROM OPEN FILES LIMIT
    
    Description:- Buffered_logs are never freed when on a server
    build with -DWITH_PERFSCHEMA_STORAGE_ENGINE=0.
    
    Analysis:- Buffered logs are neither printed nor freed on a
    server build with -DWITH_PERFSCHEMA_STORAGE_ENGINE=0. This
    is because of the conditional compilation derivative,
    "WITH_PERFSCHEMA_STORAGE_ENGINE" used inside the function,
    "init_server_components()".
    
    Fix:- The conditional derivative is removed so that even
    without performchema storage engine, buffered logs are
    printed and freed.

commit bb41c6735fde8304f2a20fc841f7107b6bb8afa3
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Apr 13 11:08:17 2016 +0530

    Bug #21616496: CREATE USER ACCEPTS PLUGIN AND PASSWORD HASH,
                   BUT IGNORES THE PASSWORD HASH
    
    Description: Creating a user with 'mysql_native_password'/
    'mysql_old_password' as plugin and using "IDENTIFIED WITH
    plugin AS 'hash_string'" as syntax, creates one without
    a password.
    
    Analysis: In 5.5 and 5.6, the "AS" part in "IDENTIFIED WITH
    ... AS <hash string>" serves a different purpose and not for
    storing the password. According to the documentation, the
    <hash string> is stored into the "authentication_string"
    column of the mysql.user table. And the password for the
    native authentication plugin is never read from this column
    instead its read from the "password" column.
    
    Fix: The bug is reclassified as a password validation plugin
    bug. The fix is to throw an error, "ERROR 1819 (HY000): Your
    password does not satisfy the current policy requirements",
    when a user is created with 'mysql_native_password'/
    'mysql_old_password' as plugin and using "IDENTIFIED WITH
    plugin AS 'hash_string'" as syntax. The error is thrown only
    if the "validate_password" plugin is installed.

commit a0e55d9602477f9d5ce963377fde575c465de6dd
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Apr 13 10:59:26 2016 +0530

    Bug#18284273: MYSQLDUMP SILENTLY QUITS WHEN IT ENCOUNTERS AN
                  ERROR.
    
    Description:- The client utility, "mysqldump" fails silently
    without printing any error message when it encounters an
    error while executing FLUSH LOGS.
    
    Analysis:- "mysqldump" uses the C API, "mysql_refresh()", to
    flush the logs. Currently no error messages are printed upon
    "mysql_refresh()" failure in "mysqldump".
    
    Fix:- Proper error messages are printed upon "mysql_refresh()"
    failure.
    
    NOTE:- mtr test case is not added since its difficult to
    simulate an error for "mysql_refresh()" through mtr.

commit 6ba5216083680d36c4becd6de14ddb798690f372
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Tue Apr 12 10:57:02 2016 +0200

    Bug#23088916 REMOVE SUPPORT-FILES/MACOSX/README.TXT
    
    This file no longer contains useful information.
    
    Fix approved by Terje Rosten <terje.rosten@oracle.com>

commit 4865ea26530ef9d6257ebecefcaeb091b06e6cb3
Merge: bc610e7 6343624
Author: Hery Ramilison <hery.ramilison@oracle.com>
Date:   Mon Apr 11 19:12:30 2016 +0200

    Merge branch 'mysql-5.6.30-release' into mysql-5.6

commit bc610e7e42011933c374cba2be665e66a3db12ed
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Thu Apr 7 11:37:32 2016 +0800

    BUG#22963169 MYSQL CRASHES ON CREATE FULLTEXT INDEX
    
    The crash is because of length mismatch.
    
    since the max length for FTS token now is larger than 255, so
    we will need to signify length byte itself, so only 1 to 128
    bytes can be used for 1 bytes, larger than that 2 bytes.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 12334

commit 1e4035d32ba333ba51962e5195d5c7f448cb0e67
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Tue Mar 22 13:03:06 2016 +0100

    Bug#22980983 ADD CMAKE OPTION TO ENABLE ALTERNATIVE SYMBOL VERSIONING IN LIBMYSQCLIENT IN 5.6
    
    Stop patching when building on Fedora, include the source protected
    by #ifdefs instead.

commit e47f04c145cf778b9ad47ad8957f42a6daaadd5b
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Mon Apr 4 12:32:48 2016 +0530

    Bug #21983865	UNEXPECTED DEADLOCK WITH INNODB_AUTOINC_LOCK_MODE=0
    
    Problem:
    =======
    This bug involves multiple thread waiting for AUTOINC_LOCK for the table
    and it leads to deadlock. Deadlock is happening because the count of
    the nodes visited exceeds the threshold limit(10^6).
    
    - Marking the subtree visited logic in the current deadlock search
    algorithm having some issue respect to table level lock.
    
    - While traversing the lock wait queue and if it reaches the current waiting
    lock then we mark the subtree as visited.
    
    - In row level lock, we are traversing from the head of the queue and eventually
    we will reach the current waiting lock in the lock wait queue.
    
    - But in table level lock, we are traversing from the tail of the queue,
    we will never reach the current waiting lock in the lock wait queue.
    
    Fix:
    ====
    
    To fix visiting subtree logic for table level lock,
    traverse from the head of the lock wait queue.
    
    Reviewed-by: Debarun Banerjee<debarun.banerjee@oracle.com>
    RB: 12147

commit da80d9f74b85fd82c07edcada999ab08cb5f3365
Author: Aditya A <aditya.a@oracle.com>
Date:   Thu Mar 31 11:06:10 2016 +0530

    Revert "Bug #21133329	HANGING "SYSTEM LOCK" WHEN EXECUTING "FLUSH TABLE ... FOR EXPORT""
    
    This reverts commit 66b7e4af49af98f8d38caf1f52f6ab0dc1cc99ab.

commit 8b75c0cfc90d3242f12621737a0d805479487151
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Wed Mar 23 11:25:50 2016 +0100

    Bug#22932576 MYSQL5.6 DOES NOT BUILD ON SOLARIS12
    
    Followup patch: extend CMAKE_SHARED_LIBRARY_CXX_FLAGS with necessary libraries.

commit 66b7e4af49af98f8d38caf1f52f6ab0dc1cc99ab
Author: Aditya A <aditya.a@oracle.com>
Date:   Wed Mar 30 11:52:21 2016 +0530

    Bug #21133329	HANGING "SYSTEM LOCK" WHEN EXECUTING "FLUSH TABLE ... FOR EXPORT"
    PROBLEM
    --------
    1. ibuf_contarct_in background() function is trying to merge
       all pages related to a certain table (which contains no record).
       while in background heavy DML operations are happening.
       When contracting the pages in ibuf_merge_space() we call
       ibuf_get_merge_pages() to get the pages to be merged.This function
       call returns the volume ( in bytes) of pages to be merged.
       In our case , the returned volume is zero since there are no pages
       to be merged ,but we increment the volume returned by 1 .
    2. This volume is returned to ibuf_contract_in_background() which
       assumes that some pages have been merged since the volume
       returned is greater than zero and waits it reach the required
       number of pages to be merged and gets stuck in the loop.
    
    FIX
    
    1. The reason we increment the volume by 1 ,is becasue for delete
       marked records the volume returned is zero and the logic in
       ibuf_merge_space() is such that acutual merging happens only
       if volume returned is non zero.
    2. To fix this we have changed the logic to merge only if the
       number of pages returned is greater than zero.We return zero
       to the ibuf_contarct_in background() when there are no pages
       to merge which enables it break the loop.
    
    [ Reviewed by Jimmy #rb12209 ]

commit e6b0330ff682370ed88f32ed27b57e193d79cf65
Merge: 947f31f 40fe95b
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Wed Mar 30 09:52:59 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 40fe95b3ee7b3c369ebd66fe37e3081362188112
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Wed Mar 23 12:59:22 2016 +0530

    BUG#22986277: DELETE-BUG22594514 UNSTABLE ON PB2
    
    Follow up patch to fix the PB2 test failure
    pushed as part of bug#22594514

commit 947f31fa0efd82a527389a81e960b2b85d6acf2e
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Mar 22 15:02:37 2016 +0530

    Bug#21697821	RELAYLOG.LOG_LOCK IS NOT RELEASED IN
    AN ERROR CASE (IN NEXT_EVENT() )
    
    Fixing post push pb2 failures

commit 23c7b8de221aded8df23b97103d94715b65f3ae9
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Thu Mar 17 16:45:26 2016 +0100

    Bug#22932576 MYSQL5.6 DOES NOT BUILD ON SOLARIS12
    
    For Sun Studio we must build with -std=c++03
    We must also remove this hack
    Since Sun Studio depends on seeing __attribute__ ((__weakref__))
    in order to generate correct code.
    
    Fix: sed -i -e 's/__attribute__/MY_ATTRIBUTE/g' `cat <list of srouce files>`

commit c48a9246f3784b8cc4cc01a9c6fc612b8b1675d4
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Mon Mar 21 15:01:14 2016 +0200

    Addendum to the fix for bug #20085672: fixed the changelog year

commit 2253722387d2bd69853655e8a179770d9f936ff9
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Mon Mar 14 18:10:45 2016 +0200

    Bug #20085672: CRYPTIC ERROR WHEN FAILING TO UNLOAD A DYNAMIC LIBRARY
    
    When the server loads a plugin it searches for globals of the
    plugin services the plugin may be using. If found it expects a version
    in these globals, checks the version and if it matches replaces it with a
    pointer to the server function implementing the service.
    It does not save these versions and thus does not restore them when
    unloading the plugin, as it expects that the dynamic library will go away.
    However if the same shared library also exports UDF functions the reference
    count to it may not be zero and UNINSTALL PLUGIN will not actually unload
    the shared library.
    So the next INSTALL PLUGIN will find the shared library, but will fail when
    checking the service versions since these are already replaced by the server
    function pointers.
    
    Fixed by accepting the relevant server function pointer as a valid value for
    the version in addition to the actual version as checked currently.
    
    Test case added.

commit c562688a1bdf408ce10db9d52954d56169b5ad7f
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Mon Mar 21 12:17:03 2016 +0530

    Bug#21697821 RELAYLOG.LOG_LOCK IS NOT RELEASED IN AN ERROR CASE (IN NEXT_EVENT())
    
    Problem: In an error case, relaylog.log_lock acquired by SQL thread is not
             released which is causing all threads, which are looking to acquire
             the lock,  are hanging.
    
    Analysis:  In next_event() function which is called by SQL thread to read
    the next even from the relay log, we have
    next_event(Rli *)
    {
       ....
        if (hot_log)
          acquire relay_log.log_lock
       .....
    
     /*
          As there is no guarantee that the relay is open (for example, an I/O
          error during a write by the slave I/O thread may have closed it), we
          have to test it.
        */
        if (!my_b_inited(cur_log))
          goto err;
    
    As you can see above, we are acquiring relay_log.log_lock but in case error
    (relay log is closed by I/O thread) we are simply returning from the next_event
    without releasing the lock. Hence any thread which will try to acquire
    relaylog.log_lock afterwards will wait forever.
    
    Fix: In the above said error case, release the relaylog.log_lock before leaving
    the function.

commit 5eb2e9e1b9d0b48940dad65a970223e055d8efad
Author: Parveez Baig <parveez.baig@oracle.com>
Date:   Fri Mar 18 17:49:42 2016 +0530

    BUG 16207800 - RPL_GTID_LOGS_WITHOUT_ROTATE_OR_STOP_EVENT TEST FAILS OCCASIONALLY ON WIN
    
      The test is failing on windows occasionally with Timeout in
     include/wait_for_slave_param.inc and some time it fails with
     symptom wrong value for slave parameter in
     include/check_slave_param.inc
    
      In the clean up phase of test we will revert GTID-based
     replication to the normal files and positions based replication
     using the change master to command by only specifying
     MASTER_AUTO_POSITION=0.But the docmentation of replication says
     If we need to revert from GTID-based replication to replication
     based on files and positions, we must use one or both of the
     options MASTER_LOG_FILE and MASTER_LOG_POS together with
     MASTER_AUTO_POSITION = 0 in the CHANGE MASTER TO command.
    
      Fix: Added the variable MASTER_LOG_FILE and MASTER_LOG_POS
     in change master to command by getting its value from the
     master using show master status.

commit 9278e07732ae4037d025a5b0b85c3675d95ab405
Merge: 634fee0 883f1fb
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Thu Mar 17 14:34:57 2016 +0100

    Merge branch 'mysql-5.5' into mysql-5.6

commit 883f1fb45198db82ca8d10bb97eb6d31421714ed
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Thu Mar 17 14:32:08 2016 +0100

    Bug#22594514: HANDLE_FATAL_SIGNAL (SIG=11) IN
                  UNIQUE::~UNIQUE | SQL/UNIQUES.CC:355
    
    Disable test case for now due to instability.
    
    Reviewed-by: Erlend Dahl <erlend.dahl@oracle.com>

commit 634fee0eef61c5d241a31f3b3d90da7fc5922d9d
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Thu Mar 17 13:25:27 2016 +0100

    Fix file permissions

commit 6f5a2f730f89c083944e468a4165cf12a7af0f87
Merge: c7902f6 85545a8
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Thu Mar 17 09:00:22 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 85545a896ae5b2e414076118a18f72c3eb97695f
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Mon Mar 14 15:20:21 2016 +0530

    BUG#22594514: HANDLE_FATAL_SIGNAL (SIG=11) IN
                  UNIQUE::~UNIQUE | SQL/UNIQUES.CC:355
    
    Analysis
    ========
    
    Enabling the sort_buffer_size with a large value
    can cause operations utilizing the sort buffer
    like DELETE as mentioned in the bug report to
    fail. 5.5 and 5.6 versions reports OOM error
    while in 5.7+, the server crashes.
    
    While initializing the mem_root for the sort buffer
    tree, the block size for the mem_root is determined
    from the 'sort_buffer_size' value. This unsigned
    long value is typecasted to unsigned int, hence
    it becomes zero. Further block_size computation
    while initializing the mem_root results in a very
    large block_size value. Hence while trying to
    allocate a block during the DELETE operation,
    an OOM error is reported. In case of 5.7+, the PFS
    instrumentation for memory allocation, overshoots
    the unsigned value and allocates a block of just
    one byte. While trying to free the block of the
    mem_root, the original block_size is used. This
    triggers the crash since the server tries to free
    unallocated memory.
    
    Fix:
    ====
    In order to restrict usage of such unreasonable
    sort_buffer_size, the typecast of block size
    to 'unsigned int' is removed and hence reports
    OOM error across all versions for sizes
    exceeding unsigned int range.

commit c7902f6227f6d626e796653569c33f05c73beba0
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Thu Mar 17 10:03:24 2016 +0800

    BUG#13651665 INNODB MAY BE UNABLE TO LOAD TABLE DEFINITION AFTER RENAME
    
    If there are 2 record one deleted, one is not, but with same table id,
    but separate on 2 pages, the current table load scheme might prematurely
    stopped at the deleted rec, and did not move to next page to locate the
    undeleted, thus false fully thought the table is deleted.
    
    Reviewed-by: Marko Mäkelä <marko.makela@oracle.com>
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 12090

commit ee21813dcd86208759eadbdd8bbf45a788fb81c3
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Tue Mar 15 11:08:29 2016 +0530

    Bug #22679185   INVALID INNODB FTS DOC ID DURING INSERT
    
    Problem:
    =======
    Insert into an InnoDB table that contains a FULLTEXT KEY and a
    FTS_DOC_ID column fail when the specified FTS_DOC_ID value as high.
    Currently the behaviour is consecutive doc_ids difference in the
    table should not exceed 10000.
    
    Solution:
    ========
    Increased the limit for consecutive doc_ids difference to 65535.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11997

commit ae7f3782de58ee5655f12833f1f61e8bdd7a9803
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Mon Mar 14 20:34:14 2016 +0800

    Followup:BUG#18614604 EMPTY/ZERO STATISTICS FOR IMPORTED TABLESPACE UNTIL
             EXPLICIT ANALYZE TABLE
    
    Fix i_innodb.innodb_fts_import failure on pb2.

commit 5af92be677671cde22c8574a56710992f42cee5d
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Wed Mar 9 13:46:54 2016 +0100

    Bug#22888420 CONCAT_WS: ASSERTION FAILED: !S.USES_BUFFER_OWNED_BY(THIS)
    
    Problem: assert in dbug mode.
    Fix: Do not assert if there is nothing to append.

commit 670dbc6f007ee32b90577fdde65d6da77989a875
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Mon Mar 14 12:01:31 2016 +0800

    BUG#18614604 EMPTY/ZERO STATISTICS FOR IMPORTED TABLESPACE UNTIL
                 EXPLICIT ANALYZE TABLE
    
    Backport rb#7428 to 5.6.

commit a61b5224f59f77a0ee245c7a42df136a80e7a204
Merge: 4b47067 2dd8b6e
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Mar 7 18:21:34 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 2dd8b6e00b7a9cb00c2c84f69b049d537c9fd388
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Mar 7 18:19:26 2016 +0530

    Bug#20685029: SLAVE IO THREAD SHOULD STOP WHEN DISK IS
    FULL
    Bug#21753696: MAKE SHOW SLAVE STATUS NON BLOCKING IF IO
    THREAD WAITS FOR DISK SPACE
    
    Fixing a post push test issue.

commit 4b47067d6e74a5493d0604afed3d852d03092771
Author: Aditya A <aditya.a@oracle.com>
Date:   Thu Mar 3 17:02:53 2016 +0530

    Bug# 22865112 LACK OF HTONLL CHECK CAUSE MYSQ5.6.30/5.7.12 BUILD FAILURE ON OS X
    
    PROBLEM
    -------
    
    Build failure in some mac machines due to redefinition of htonll function.
    
    FIX
    ---
    Introduced a check to not redefine htonll if OS provides htonll function.

commit ab5db1fccdbd4afd63acf186ccdbb9ba5ee215bc
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Mar 3 14:21:24 2016 +0530

    Bug #22187476: LOCK IN SHARED MODE AND FOR UPDATE CAUSE TOO
                   MANY CRASHES.
    
    Post-push fix for mysql-5.6.
    
    1) Accidentally reverted a previous change in opt_range.cc.
    This has been corrected.
    2) The result file's explain output belonged to 5.7. This
    has also been corrected.

commit 39851d64940fdaa2d8281cef37b0cdb90634d041
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Mar 3 07:59:34 2016 +0530

    Bug #22187476: LOCK IN SHARED MODE AND FOR UPDATE CAUSE TOO
                   MANY CRASHES.
    
    ISSUE:
    ------
    The problem occurs in the following circumstances:
    1) When two or more parallel connections result in a
       deadlock detected by INNODB.
    2) The query that causes the deadlock is a
       "SELECT ...GROUP BY ....FOR UPDATE" that uses loose
       index scan.
    
    SOLUTION:
    ---------
    When INNODB returns "HA_ERR_LOCK_DEADLOCK" (or any other
    error code), this is not handled by the part of range
    optimizer that deals with loose index scan. This error
    code will now be passed on to the calling function.

commit bab190af774afc10bd57b6e44b8536238d510087
Merge: 060bcee d138c73
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Mar 3 06:44:31 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit d138c733e4c4a7fd667c3b7826a908727031fe6f
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Mar 3 06:42:12 2016 +0530

    Bug #18740222: CRASH IN GET_INTERVAL_INFO WITH WEIRDO
                   INTERVALS
    
    ISSUE:
    ------
    Some string functions return one or a combination of the
    parameters as their result. Here the resultant string's
    charset could be incorrectly set to that of the chosen
    parameter.
    
    This results in incorrect behavior when an ascii string is
    expected.
    
    SOLUTION:
    ---------
    Since an ascii string is expected, val_str_ascii should
    explicitly convert the string.
    
    Part of the fix is a backport of Bug#22340858 for mysql-5.5
    and mysql-5.6.

commit 060bceee57d187f08559c968b44944550074aa45
Merge: 1627275 0bd6719
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Tue Mar 1 13:09:18 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 0bd6719c227addd89f997c358dee5bab90b4ad7f
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Tue Mar 1 13:05:14 2016 +0530

    Bug#19920049 - MYSQLD_MULTI MISLEADING WHEN MY_PRINT_DEFAULTS
                   IS NOT FOUND
    
    DESCRIPTION
    ===========
    If script mysqld_multi and utility my_print_defaults are in
    the same folder (not included in $PATH) and the former is
    made to run, it complaints that the mysqld binary is absent
    eventhough the binary exists.
    
    ANALYSIS
    ========
    We've a subroutine my_which() mimicking the behaviour of
    POSIX "which" command. Its current behaviour is to check
    for a given argument as follows:
    - Step 1: Assume the argument to be a command having full
    fledged absolute path. If it exists "as-is", return the
    argument (which will be pathname), else proceed to Step 2.
    - Step 2: Assume the argument to be a plain command with no
    aboslute path. Try locating it in all of the paths
    (mentioned in $PATH) one by one. If found return the
    pathname. If found nowhere, return NULL.
    
    Currently when my_which(my_print_defaults) is called, it
    returns from Step 1 (since utlity exists in current
    folder) and doesn't proceed to Step 2. This is wrong since
    the returned value is same as the argument i.e.
    'my_print_default' which defies the purpose of this
    subroutine whose job is to return a pathname either in Step
    1 or Step 2.
    
    Later when the utility is executed in subroutine
    defaults_for_group(), it evaluates to NULL and returns the
    same. This is because the plain command 'my_print_defaults
    {options} ...' would execute properly only if
    my_print_defaults exists in one of the paths (in $PATH). In
    such a case, in the course of the flow it looks onto the
    variable $mysqld_found which comes out to be NULL and
    hence ethe error.
    
    In this case, call to my_which should fail resulting in
    script being aborted and thus avoiding this mess.
    
    FIX
    ===
    This utility my_print_defaults should be tested only in
    Step 2 since it does not have an absolute path. Thus added
    a condition in Step 1 so that is gets executed iff not
    called for my_print_defaults thus bypassing it to proceed
    to Step 2 where the check is made for various paths (in
    $PATH)

commit 1627275002327acdcb5083aa6c6846688f4a591d
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Tue Mar 1 12:44:53 2016 +0530

    Bug#21507981: REPLICATION POSITION LOST AFTER CRASH ON MTS
    CONFIGURED SLAVE
    
    Problem:
    ========
    Enable MTS along with crash-safe replication tables. Make
    sure that the server is busily inserting data with multiple
    threads in parallel. Shutdown mysqld uncleanly (kill -9 or
    power off server without notice).
    
    Now users are restarting the server with
    --relay-log-recovery=1 to recover the crashed slave.
    
    This results in following error:
    ================================
    2015-06-24 13:49:03 3895 [ERROR] --relay-log-recovery cannot
    be executed when the slave was stopped with an error or
    killed in MTS mode; consider using RESET SLAVE or restart
    the server with --relay-log-recovery = 0 followed by
    START SLAVE UNTIL SQL_AFTER_MTS_GAPS.
    
    i.e relay-log-recovery will not work in MTS mode.
    
    Manual steps that are followed to fix this issue:
    ================================================
    1) The server has to be restarted with –-relay-log-recovery= 0.
    2) Execute START SLAVE UNTIL SQL_AFTER_MTS_GAPS.
    This step will ensure that gaps are filled and the slave will
    stop at this point.
    3) Restart the slave server with ‘relay-log-recovery=1’.
    
    Analysis:
    ========
    The above mentioned process involves manual intervention.
    This needs to be automated.
    
    Fix:
    ====
    During crash recovery if gaps are present in MTS execution
    then START SLAVE UNTIL SQL_AFTER_MTS_GAPS is invoked
    implicitly and the gaps are filled. Once slave reaches this
    gap less consistent state it will stop. Then initialize the
    Receiver thread's positions to the latest Applier thread's
    positions and discard the old relay logs as we do in the
    case of single threaded slave mode.
    
    This recovery process may not work if MTS has stopped due to
    an error during an earlier session in that case appropriate
    error message will be printed. Users will have to eliminate
    the route cause of the error and restart the recovery
    process.

commit 749b93441d49b923319b4a9e08a179443373672c
Merge: 2c6e095 c3dcf8e
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Tue Mar 1 12:32:15 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit c3dcf8e5a8fdea776258c43a0e4a9e5ca5d5772a
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Tue Mar 1 12:29:51 2016 +0530

    Bug#20685029: SLAVE IO THREAD SHOULD STOP WHEN DISK IS
    FULL
    Bug#21753696: MAKE SHOW SLAVE STATUS NON BLOCKING IF IO
    THREAD WAITS FOR DISK SPACE
    
    Problem:
    ========
    Currently SHOW SLAVE STATUS blocks if IO thread waits for
    disk space. This makes automation tools verifying
    server health block on taking relevant action. Finally this
    will create SHOW SLAVE STATUS piles.
    
    Analysis:
    =========
    SHOW SLAVE STATUS hangs on mi->data_lock if relay log write
    is waiting for free disk space while holding mi->data_lock.
    mi->data_lock is needed to protect the format description
    event (mi->format_description_event) which is accessed by
    the clients running FLUSH LOGS and slave IO thread. Note
    relay log writes don't need to be protected by
    mi->data_lock, LOCK_log is used to protect relay log between
    IO and SQL thread (see MYSQL_BIN_LOG::append_event). The
    code takes mi->data_lock to protect
    mi->format_description_event during relay log rotate which
    might get triggered right after relay log write.
    
    Fix:
    ====
    Release the data_lock just for the duration of writing into
    relay log.
    
    Made change to ensure the following lock order is maintained
    to avoid deadlocks.
    
    data_lock, LOCK_log
    
    data_lock is held during relay log rotations to protect
    the description event.

commit 2c6e095afac0b6272c8ee7c2290bf4ad80ebe4e3
Merge: d77441f 7c955a2
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Mar 1 11:59:16 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 7c955a2f134178afdb5644c324c5c64a7ee3c370
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Mar 1 11:58:45 2016 +0530

    BUG#17018343 SLAVE CRASHES WHEN APPLYING ROW-BASED BINLOG ENTRIES IN CASCADING
    REPLICATION
    
    Problem: In RBR mode, merge table updates are not successfully applied on a cascading
    replication.
    
    Analysis & Fix: Every type of row event is preceded by one or more table_map_log_events
    that gives the information about all the tables that are involved in the row
    event. Server maintains the list in RPL_TABLE_LIST and it goes through all the
    tables and checks for the compatibility between master and slave. Before
    checking for the compatibility, it calls 'open_tables()' which takes the list
    of all tables that needs to be locked and opened. In RBR, because of the
    Table_map_log_event , we already have all the tables including base tables in
    the list. But the open_tables() which is generic call takes care of appending
    base tables if the list contains merge tables. There is an assumption in the
    current replication layer logic that these tables (TABLE_LIST type objects) are always
    added in the end of the list. Replication layer maintains the count of
    tables(tables_to_lock_count) that needs to be verified for compatibility check
    and runs through only those many tables from the list and rest of the objects
    in linked list can be skipped. But this assumption is wrong.
    open_tables()->..->add_children_to_list() adds base tables to the list immediately
    after seeing the merge table in the list.
    
    For eg: If the list passed to open_tables() is t1->t2->t3 where t3 is merge
    table (and t1 and t2 are base tables), it adds t1'->t2' to the list after t3.
    New table list looks like t1->t2->t3->t1'->t2'. It looks like it added at the
    end of the list but that is not correct. If the list passed to open_tables()
    is t3->t1->t2 where t3 is merge table (and t1 and t2 are base tables), the new
    prepared list will be t3->t1'->t2'->t1->t2. Where t1' and t2' are of
    TABLE_LIST objects which were added by add_children_to_list() call and replication
    layer should not look into them. Here tables_to_lock_count  will not help as the
    objects are added in between the list.
    
    Fix: After investigating add_children_list() logic (which is called from open_tables()),
    there is no flag/logic in it to skip adding the children to the list even if the
    children are already included in the table list. Hence to fix the issue, a
    logic should be added in the replication layer to skip children in the list by
    checking whether  'parent_l' is non-null or not. If it is children, we will skip 'compatibility'
    check for that table.
    
    Also this patch is not removing 'tables_to_lock_count' logic for the performance issues
    if there are any children at the end of the list, those can be easily skipped directly by
    stopping the loop with tables_to_lock_count check.

commit d77441fa6cbbbba262a735097d65f87f3b498d46
Merge: cb420b9 94f1a3a
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Tue Mar 1 10:21:28 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 94f1a3a8e479a50ad7d5ed2b226afeebfaf652f5
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Tue Mar 1 10:17:25 2016 +0530

    Bug#21920657: SSL-CA FAILS SILENTLY IF THE PATH CANNOT BE
                  FOUND
    
    Description:- Failure during the validation of CA
    certificate path which is provided as an option for 'ssl-ca'
    returns two different errors for YaSSL and OPENSSL.
    
    Analysis:- 'ssl-ca', option used for specifying the ssl ca
    certificate path. Failing to validate this certificate with
    OPENSSL returns an error, "ERROR 2026 (HY000): SSL
    connection error: SSL_CTX_set_default_verify_paths failed".
    While YASSL returns "ERROR 2026 (HY000): SSL connection
    error: ASN: bad other signature confirmation". Error
    returned by the OPENSSL is correct since
    "SSL_CTX_load_verify_locations()" returns 0 (in case of
    OPENSSL) for the failure and sets error as
    "SSL_INITERR_BAD_PATHS". In case of YASSL,
    "SSL_CTX_load_verify_locations()" returns an error number
    which is less than or equal to 0 in case of error. Error
    numbers for YASSL is mentioned in the file,
    'extra/yassl/include/openssl/ssl.h'(line no : 292). Also
    'ssl-ca' does not accept tilde home directory path
    substitution.
    
    Fix:- The condition which checks for the error in the
    "SSL_CTX_load_verify_locations()" is changed in order to
    accommodate YASSL as well. A logic is written in
    "mysql_ssl_set()" in order accept the tilde home directory
    path substitution for all ssl options.

commit cb420b9a9772e3895ee28500ffd84b3bca9298b2
Merge: bafbd56 1c7233b
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Feb 29 14:03:11 2016 +0100

    Raise version number after cloning 5.6.30

commit 1c7233b1ba850cfea003f472c6c62a05009f77be
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Feb 29 13:58:41 2016 +0100

    Raise version number after cloning 5.5.49
