commit e56856264e03400ce95946e655702f501d191837
Author: Sreedhar Sreedhargadda <sreedhar.sreedhargadda@oracle.com>
Date:   Mon Feb 1 11:38:43 2016 +0100

    Fix for post WL#5769(removal of keyring directory for Windows)
    
    (cherry picked from commit d9158ac140c68174c5ba1fd63bd92bd1dc817d2a)

commit 4fdbec1d27237679fa3528ef2157cb7d8b75a2f6
Merge: bbd55cd ed4c169
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Feb 1 22:03:57 2016 +0100

    Merge tag 'mysql-5.7.10-2' into mysql-5.7.11-release
    
    Conflicts:
    	packaging/rpm-oel/mysql.init

commit bbd55cd8ebf0cbdb7e89715be5f1e2649a281447
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Wed Jan 27 18:46:40 2016 +0530

    BUG#22600974 - SYSV INITSCRIPT FOR RHEL DON'T ENABLE MYSQLD SERVICE BY DEFAULT
    
      Enable mysqld service by default in sysv initscrips
    
    (cherry picked from commit 0fe41fe79983a8bae89c630adc2ed7dd4fe43607)

commit 415737e61a4306fb75a37a16e11e472a5d5dbead
Author: Robert Golebiowski <robert.golebiowski@oracle.com>
Date:   Fri Jan 22 16:39:52 2016 +0100

    Bug #22520464 TDE: TEST CASES GET HANG ON FREEBSD
    
    TDE test cases keep hanging on FreeBSD.
    
    (cherry picked from commit 090afde0c1b9356c116ccf07119da5b9d99b3511)

commit fc6ac33814bcc2eb7c8765a35dfd51381ef17ea2
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Tue Jan 26 11:11:52 2016 +0100

    Fix copyright header for postinst scripts
    
    (cherry picked from commit 958c4cbeffe7966bfc8bfb87c67d35b6310d21d5)

commit 841c4269e640aded242b584e6e5f330304538f91
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Mon Jan 25 11:49:44 2016 +0100

    Bug#22594846 ROOT USER CREATED WITH AUTH_SOCK PLUGIN EVEN ROOT PWD IS NOT BLANK
    
    Configuration script was storing password in commercial-labelled variable,
    but trying to fetch it from community-labelled. Caused it to think password
    was empty regardless of user input, and install user with auth_sock
    
    (cherry picked from commit 2c8d36a19a2b1a2c6c2a614078222248066153f9)

commit bb0e017744031d1fa15104afa73aaf36de5de658
Author: Harin Vadodaria <harin.vadodaria@oracle.com>
Date:   Fri Jan 22 16:54:27 2016 +0530

    Bug#22573767: MYSQLD --VERBOSE --HELP TRIES TO INITIALIZE KEYRING FILE
    
    Problem: If a plugin is provided through --early-plugin-load,
             server tries to initialize it even if --help is specified.
    
    Solution: Skip plugin initialization if --help is used.
    
    Reviewed-By: Georgi Kodinov <georgi.kodinov@oracle.com>
    (cherry picked from commit fc3e3d23729763a024e6473e72444357b8f899d4)

commit 5bc104b37dd697a610d2015e97335580041da455
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Tue Jan 19 15:34:22 2016 +0530

    Follow-up fix for Bug#22559624 KEYRING_FILE INITIALIZATION FAILURE WHEN SELINUX ENABLED FROM DISABLED STATE
    
    (cherry picked from commit 4fbd07124168ef24eba5b55a0e3d90a5478aa1fe)

commit 79190200a2f4720c0c98cc9d255f4aee66f0c409
Author: Ramil Kalimullin <ramil.kalimullin@oracle.com>
Date:   Wed Jan 13 19:44:45 2016 +0400

    WL#8785: Support multi-state SSL option.
    
    After push test fixes:
      i_rpl.rpl_semi_sync_shutdown
      rpl.rpl_multi_source_mts_reset_worker_info
      rpl.rpl_semi_sync_after_sync
      rpl.rpl_semi_sync_shutdown_hang
    
    (cherry picked from commit 72b8fad8daabbe8243019825cde2038815d66f7d)

commit 1fc2b8945072a509ed7bbb565bd944107d184bda
Author: Catalin Besleaga <catalin.besleaga@oracle.com>
Date:   Wed Jan 13 14:09:57 2016 +0100

    BUG#22541713: Error message uses UK English, not US English
    
    Changed "behaviour" to "behavior" in the messages produced by
    deprecation warning introduced in 5.7.11 for bit operations on
    BINARY/VARBINARY arguments.
    
    (cherry picked from commit a929f0ed4376e850f5b34fe615741eab6c932a97)

commit 68972ab875b5463bdcf0f1c0fa903c88e7c185ed
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Mon Jan 18 17:55:14 2016 +0530

    Bug#22559624 KEYRING_FILE INITIALIZATION FAILURE WHEN SELINUX ENABLED FROM DISABLED STATE
    
      Fix to initialize /var/lib/mysql-keyring when SELinux is enabled.
      Add /var/lib/mysql-keyring directory to file-contexts
    
    (cherry picked from commit c798fb6f39e778ae85806b29d7255b45ede98a47)

commit 1192cd57c55750a76e6c2ed1e57e0aecac997d48
Author: Robert Golebiowski <robert.golebiowski@oracle.com>
Date:   Wed Jan 13 14:58:21 2016 +0100

    Bug #22540394: ASSERT FAILURE IN KEYRING_FILE.SO (MEMORY_SIZE %
    SIZEOF(SIZE_T) == 0)
    
    (cherry picked from commit 5acbbaab4bf97841590a5d862b0bc6ebb9399387)

commit 6a14f8a2794b988e7dec8bdbf5b19763d5d69490
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Fri Jan 15 13:28:55 2016 +0800

    Fixed bug#22538749 IMPORT OF ENCRYPTED DBSPACE FAILS WITH MASTER KEY ERROR
    
    In importing, we need to skip getting key information from data file. The
    key information should be acheived from .cfp file.
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
    RB: 11492
    (cherry picked from commit 2091b92ff866f0109e8bd4801e827473d5dfa955)

commit faf6ba4482b4596b9f50a8ea189304628540ee8e
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Thu Jan 14 09:45:55 2016 +0800

    Fixed TDE bugs:
    bug#22514564 TDE:INNODB:ASSERTION FAILURE IN THREAD 139878949578496 IN FILE UT0UT.CC LINE 920
    bug#22522122 TWO TYPOS IN ERROR ER_INVALID_ENCRYPTION_OPTION
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
    RB: 11462
    (cherry picked from commit bd2e8ce2075ed29fe24c28d14e764e43426be02b)

commit bbb5b1fcc515bb71ef999f4fb082448c349d9110
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Wed Jan 13 12:20:11 2016 +0100

    Fixed copyright header for keyring-test.cc

commit 935bb6a84587635b8d7a0226684cfaf32e29716f
Merge: 8fffeea 0f5490c
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Jan 11 14:24:04 2016 +0100

    Updated copyright year in user visible text

commit 0f5490c7fff651091d1bc0947ad26c1712df390e
Merge: 415f65b d4115d9
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Jan 11 14:20:36 2016 +0100

    Updated copyright year in user visible text

commit d4115d987d630ea5a61dc35f314efdbea0d5d3e2
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Jan 11 14:10:58 2016 +0100

    Updated copyright year in user visible text

commit 8fffeea589535f1f293a33e45f9e3f05812bbd55
Merge: 916cc1c 415f65b
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 14:53:07 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 415f65b500798631f8b8fa090e53984d3c04935a
Merge: 8ebc5ee da96d6b
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 14:45:15 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit da96d6beae895c880da7df778281ebc10ec31bcc
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 14:44:49 2016 +0530

    Bug #22295186:   CERTIFICATE VALIDATION BUG IN MYSQL MAY ALLOW MITM
    
    Test fix for 5.5 and 5.6

commit 916cc1c4444a2fd98b28e18e8aa26aa67eb825e4
Author: Harin Vadodaria <harin.vadodaria@oracle.com>
Date:   Mon Jan 11 12:44:35 2016 +0530

    Bug#22522079: CRASH WHEN SETTING KEYRING_FILE_DATA=NULL
    
    Issue : A NULL string for keyring_file_data was not handled properly
    
    Solution : Added required check.

commit 89bfb27cc4711815fa8226b9de436802948348e7
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Mon Jan 11 12:53:43 2016 +0800

    Followup patch of TDE wls to fix valgrind failure and windows failure.

commit 7b6adbc3112e994c35f89dd97f3cfb8dd6afda30
Merge: 91b054a 8ebc5ee
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 09:25:36 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 8ebc5ee5ea1763ad09b39d1e926d4e551f51d1d0
Merge: 928663a 648d587
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 09:24:06 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 648d5877241a235e3870b6043ca94a543271f579
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 09:23:31 2016 +0530

    Bug #22295186:    CERTIFICATE VALIDATION BUG IN MYSQL MAY ALLOW MITM.
    
    Test Fix

commit 91b054abeb98bc1a9124be9702c95fe5c3741ed6
Merge: eb77d98 928663a
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 07:14:10 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 928663a01464d59abf2d9b9184b675447a219806
Merge: d0148e9 041bd3b
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 07:13:51 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6
    
    Conflicts:
    	sql-common/client.c

commit 041bd3b4457959db4925e6f8788790882634e945
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Mon Jan 11 07:09:13 2016 +0530

    Bug #22295186:  CERTIFICATE VALIDATION BUG IN MYSQL MAY ALLOW MITM

commit eb77d9854638ca998ae1353223d7aaff53c0d6f6
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Sun Jan 10 15:25:02 2016 +0800

    Fixed testcase table_encrypt_1 failure on windows.

commit 81ab6acaf171140b68bc40de2fbcf3500eed446a
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Sun Jan 10 10:41:49 2016 +0800

    Fixed testcase failure of TDE push.
    
    They're all test case issues.

commit 12847b8b5c2b7f2e809906b690d6effb66ed2995
Author: Harin Vadodaria <harin.vadodaria@oracle.com>
Date:   Sat Jan 9 16:29:29 2016 +0530

    WL#5769, WL#8821 and WL#8548
    
    WL#5769: Keyring service for MySQL
    - Added keyring service
    - Added file based keyring plugin : keyring_file
    
    WL#8821: Innodb tablespace encryption key rotation
             SQL commands
    - Added syntax and server support for master key
      rotation SQL:
      ALTER INSTANCE ROTATE INNODB MASTER KEY
    - Added support to load plugin before mandatory/built-in
      plugins using new option : --early-plugin-load
    - Added support for compile time default for
      --early-plugin-load
    
    WL#8548: InnoDB: Transparent data encryption
    - Added new option for table creation for enablin
      data encryption : ENCRYPTION="Y"/"N"
    - Added transparent data encryption using keyring service
    - Added support for master key rotation
    - Added support for import/export of encrypted tablespace

commit c4b4449d844ddfc23571586dc248634e85a42bb5
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Fri Jan 8 15:43:00 2016 +0100

    Bug#22377554: server crash after updating/inserting into table with trigger
    
    Some activations of triggers that referenced a NEW value inside a
    query might experience a server exit.

commit 317b7f440ea0614d7b6b886c0ac4809864c43e79
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Jan 8 20:25:13 2016 +0530

    Bug #22204260   PURGE TRIES TO ACCESS FREED PAGE FOR VIRTUAL INDEX
    
    	- Post push fix because embedded server doesn't support restart.

commit fad21c71d2269572d0115a1fb02f585fad0ebf34
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Jan 8 20:02:20 2016 +0530

    Bug #22204260   PURGE TRIES TO ACCESS FREED PAGE FOR VIRTUAL INDEX
    
    Analysis:
    ========
    
    1) Purge is trying to build "current image" of virtual columns
    from the current cluster index, even it is deleted since the
    old version will depend on it.
    
    2) The old version took a short cut, build tuple out of
    this delete marked rec for all columns (including non-virtual columns).
    
    3) The problem with old one is that the BLOB page can be freed, so
    building the tuple out of it will trigger error.
    
    Fix:
    ====
    1) No need to build tuple on non-virtual columns at all.
    
    2) Build only virtual column, and it exist in undo log.
    
    3) So there is no need to fetch the whole blob, only prefix of it
    (that can be fetched from undo_log).
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    Reviewed-by: Marko Makela <marko.makela@oracle.com>
    RB: 11442

commit ee1118ff9777b720f854ef4cb5f3f1c98f140d4c
Merge: 2f08951 d0148e9
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Fri Jan 8 14:57:40 2016 +0100

    NULL Merge branch 'mysql-5.6' into mysql-5.7
    
    Conflicts:
    	libmysql/CMakeLists.txt
    	scripts/mysql_config.sh
    	sql/CMakeLists.txt

commit d0148e9fda868be70f73584a95bf50b2b5ea7f1b
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Wed Jan 6 16:42:13 2016 +0100

    Bug#22504264 MYSQL COMMUNITY SERVER PACKAGE FOR SOLARIS 10 X86/AMD64 BROKEN
    
    Our binaries depend on libstlport, which is not part of Solaris by default,
    so we ship it as part of mysql packages.
    
    The problem was that this dependency was not noted in the client library.
    
    Fix: bacport more from:
       Bug#16555106 FIX BROKEN BUILD WITH SOLARIS/GCC 64BIT MODE
    
    Specifically: add -R$ORIGIN/../lib when linking the client library.

commit 2f08951c5c58da591eabf1c97cbc2d94dfcd7e13
Author: Aditya A <aditya.a@oracle.com>
Date:   Fri Jan 8 11:59:03 2016 +0530

    Bug #22502629    PB2 FAILURE OF TEST CASE INNODB.LOG_FILE_SIZE_CHECKPOINT
    
    This is a temporary workaround to fix the failure for
    log_file_size_checkpoint, which would fail with:
     --mysqld--innodb_undo_tablespaces=5 --mysqld=--innodb_page_size=64k
     We raise the buffer pool size in this workaround, but we still want the
     final fixes from these two:
     Bug#22179133 - INNODB: TOO SMALL BUFFER POOL FOR INNODB_PAGE_SIZE=64K
     Bug#22186325 - INNODB: CRASH RECOVERY CAN RUN OUT OF BUFFER POOL
    
    Approved by deb in IM

commit d5a3b6b4122786d02612785f70fb2d8e7fc47320
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Fri Jan 8 06:50:01 2016 +0100

    Correct typo in mysql-test/suite/binlog/t/binlog_gtid_state_update_deadlock.test

commit b8dbe5848b3b888a6951770011790eff97994ffe
Merge: b32cd56 c0cd5f6
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Jan 8 06:51:42 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit c0cd5f674ef6bd7d8c3d73e51aef87e3681a4d70
Merge: 042ac81 021794e
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Jan 8 06:50:49 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 021794eb3079c727200c4eaae547f83a71197d35
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Jan 8 06:46:59 2016 +0530

    Bug #22232332: SAVING TEXT FIELD TO TEXT VARIABLE IN A
                   PROCEDURE RESULTS IN GARBAGE BYTES
    
    Issue:
    -----
    This problem occurs under the following conditions:
    
    a) Stored procedure has a variable is declared as TEXT/BLOB.
    b) Data is copied into the the variable using the
       SELECT...INTO syntax from a TEXT/BLOB column.
    
    Data corruption can occur in such cases.
    
    SOLUTION:
    ---------
    The blob type does not allocate space for the string to be
    stored. Instead it contains a pointer to the source string.
    Since the source is deallocated immediately after the
    select statement, this can cause data corruption.
    
    As part of the fix for Bug #21143080, when the source was
    part of the table's write-set, blob would allocate the
    neccessary space. But this fix missed the possibility that,
    as in the above case, the target might be a variable.
    
    The fix will add the copy_blobs check that was removed by
    the earlier fix.

commit b32cd56dfd3784bca494b8cc52df54238f031aa0
Author: Christopher Powers <chris.powers@oracle.com>
Date:   Wed Jan 6 12:02:47 2016 -0600

    Bug#22513239 PERFSCHEMA.SHOW_PLUGIN FAILS SPORADICALLY ON PB2
    
    Plugin-defined session variables sometimes remain after the client
    disconnects. Inserted wait_until_disconnect to ensure proper timing
    between session disconnect and subsequent system variable queries.

commit f495a48b9cdf1bca3bc6c7b597612e1cadaa3389
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Thu Jan 7 16:52:20 2016 +0100

    Bug#22370382 SUM(DISTINCT ...) GIVES WRONG RESULT
    Bug#11764126 SUM(DISTINCT) GIVES WRONG RESULT WHEN REDUCING MAX_HEAP_TABLE_SIZE
    
    MySQL server creates in-memory data structures in order to execute
    queries of the form
      SELECT SUM(DISTINCT col) sm FROM tab;
    The size of those data structures is limited by the value of the
    system variable max_heap_table_size.
    
    If the table contains many distinct values, intermediate data will be
    written to disk, and later re-merged. There was a bug in this
    merge algorithm, which may lead to incorrect results.
    The workaround was to increase the value of max_heap_table_size.
    
    This patch fixes the merge algorithm.

commit 48f1310571c83aa87f73907dc687fcc26fe67483
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Thu Jan 7 16:00:22 2016 +0200

    WL#8785 addendum: fixed a leak in mysql_reconnect by
    freeing the options allocated before reusing them.

commit 1bf8bc77a115b84ea8066b7b7b3175518c5810cc
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Thu Jan 7 11:50:02 2016 +0200

    Squashed commit of the following:
    
    commit 7f3899966f0d4d03e0d2dfefa027beb791753177
    Author: Ramil Kalimullin <ramil.kalimullin@oracle.com>
    Date:   Sun Dec 20 12:15:49 2015 +0400
    
        WL#8785: Support multi-state SSL option.
    
        Introduce the --ssl-mode option.
        Introduce the MYSQL_OPT_SSL_MODE mysql_optiopns() option.
        Deprecate the --ssl option
        Deprecate MYSQL_OPT_SSL_ENFORCE and MYSQL_OPT_SSL_VERIFY_SERVER_CERT
    
        (cherry picked from commit 989ca573ab72ba9f2843ebe77d7c4484fd9ea460)
        Backported to 5.7.
        Changes:
        * undone the renaming to unused in include/mysql.h to keep with
        the binary compatibility.
        * moved the option at the end of the 5.7 options in the options enum.
        * updated the copyright year
        * Bumped the minor C API version
        * Made --ssl and --ssl-verify-server-cert have an effect in the new framework

commit 5cb425ff7698ec89b8a3ef5cd3793f6178763a15
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Thu Jan 7 10:10:07 2016 +0100

    Mark some tests that take too long as 'big' tests
    
    i_main.pid_file_issue
    binlog.binlog_gtid_state_update_deadlock
    sysschema.v_schema_auto_increment_columns
    
    Approved by Jon Olav Hauglid <jon.hauglid@oracle.com>

commit c542592ccc1a837b15ac50eb6e9d2cb2bc7ac26e
Merge: 6e7baa9 042ac81
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Thu Jan 7 14:44:48 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 042ac813f52e97576298dfe9ee01ff5cdf056548
Merge: 2242395 86e3f8e
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Thu Jan 7 14:43:47 2016 +0530

    Bug#21770366 backport bug#21657078 to 5.5 and 5.6
    
    Problem Statement
    =========
    Fix various issues when building MySQL with Visual Studio 2015.
    
    Fix:
    =======
    - Visual Studio 2015 adds support for timespec. Add check for
      this and only use our replacement if timespec is not defined.
    - Rename lfind/lsearch to my* to avoid redefinition problems.
    - Set default value for TMPDIR to "" on Windows as P_tmpdir
      no longer exists.
    - using VS definition of snprintf if available
    - tzname are now renamed to _tzname.
    - This patch raises the minimum version required of WiX Toolkit
      to 3.8, which is required to make MSI packages with
      Visual Studio 2015

commit 86e3f8edde0c1fcb3e910195b95f80684ad0522f
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Thu Jan 7 14:36:19 2016 +0530

    Bug#21770366 backport bug#21657078 to 5.5 and 5.6
    
    Problem Statement
    =========
    Fix various issues when building MySQL with Visual Studio 2015.
    
    Fix:
    =======
    - Visual Studio 2015 adds support for timespec. Add check and
      related code to use this and only use our replacement if
      timespec is not defined.
    - Rename lfind/lsearch to my* to avoid redefinition problems.
    - Set default value for TMPDIR to "" on Windows as P_tmpdir
      no longer exists.
    - using VS definition of snprintf if available
    - tzname are now renamed to _tzname.

commit 6e7baa97619dc5a84879a676d87b5fc67a22d0af
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Thu Jan 7 13:02:21 2016 +0530

    Bug #22384503   BLOCK MEMCACHED FROM MODIFYING TABLES THAT
                    CONTAIN INDEXED VIRTUAL COLUMNS
    
    Problem:
    =======
    
    Accessing the virtual column for the table involves callback to
    the server. But memcached doesn't have access to server code.
    
    Fix:
    ====
    
    Block the memcached from accessing the table contains virtual column.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11368

commit 58dbfeb9bf2e4a069bbbd071ed1e25e86abaee70
Author: Bharathy Satish <bharathy.x.satish@oracle.com>
Date:   Thu Jan 7 10:06:27 2016 +0530

    Bug#21399236 MYSQLPUMP TESTS FAIL DUE TO NON EXISTENT TABLE/DB
    Bug#21447753 MYSQLPUMP TESTS FAILS ON PB2 WITH SEGMENTATION FAULT
    
    Problem: Due to race condition issues there were random crashes happening.
    
    Solution: Identified the race conditions in the code using valgrind and
    fixed data race issues.
    
    Problem: Test failing due to non existent table/db is due to bad thread
    synchronization when processing views while taking dump.
    For ex:
    CREATE VIEW db1.v1 AS SELECT * FROM t2;
    CREATE VIEW db1.v2 AS SELECT * FROM t1;
    CREATE VIEW db1.v3 AS SELECT db1.v1.*,db1.v2.a as X FROM db1.v1,db1.v2;
    If above views are dumped in following order, then during restore we get
    an error saying db1.v2 does not exists.
    
    DROP VIEW IF EXISTS db1.v1;
    CREATE VIEW db1.v1 AS select db1.dt2.a AS a,db1.dt2.b AS b from db1.dt2;
    DROP VIEW IF EXISTS db1.v2;
    DROP VIEW IF EXISTS db1.v3;
    CREATE VIEW db1.v3 AS select v1.a AS a,v1.b AS b,v2.a AS X from
    (db1.v1 join db1.v2);
    CREATE VIEW db1.v2 AS select db1.dt1.a AS a from db1.dt1;
    
    Solution: When processing views DROP VIEW followed by CREATE VIEW
    statements are dumped as an atomic operation.

commit 0520c69e0280056ac2a4111e3f53559b88fe785a
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Wed Jan 6 12:09:49 2016 +0100

    Bug#22455198: THREAD HANDLE LEAK IN THE CONNECTION HANDLER
    
    The problem was a thread handle resource leakage when creating
    threads for handling connections on Windows. This could lead
    to Windows servers eventually running out of handles.
    
    This was a regression introduced in 5.7 by WL#6407. In this
    WL we added support for joining threads on Windows in order
    to do proper thread cleanup during shutdown. In order to
    do this we had to keep the thread handle open as it is
    needed for joining the thread.
    
    The bug was that the handle was kept open also for threads
    that are detached. Such threads are never joined and thus
    the handle was not closed until the server terminated.
    The (by far) most common type of thread which is detached,
    is threads for handling connections.
    
    This patch fixes the problem by closing thread handles
    right after thread creation if the thread is created as
    a detached thread.

commit d8642503337492669a19fdd2f8b2e3ffac624d81
Merge: 894cbdb 2242395
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Jan 6 19:42:44 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 224239501ad5a571e0f3fc41bc5c1d65094a7bba
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Jan 6 19:41:00 2016 +0530

    Bug #17883203 : MYSQL EMBEDDED MYSQL_STMT_EXECUTE RETURN
                    "MALFORMED COMMUNICATION PACKET" ERROR
    
    Post push to fix valgrind test case failure in pb2.

commit 894cbdb0fe16ca60a49694ed31d645ed09717771
Author: Norvald H. Ryeng <norvald.ryeng@oracle.com>
Date:   Wed Jan 6 10:28:09 2016 +0100

    Bug#22306745 ST_BUFFER DOES NOT WORK FOR NON CARTESIAN COORDINATES IN
    MYSQL V5.7
    
    Problem: ST_Buffer returns an error message when passed a geometry
    with SRID different from 0.
    
    Fix: Allow geometries with SRID != 0. All calculations will still be
    Cartesian since the server doesn't support non-Cartesian spatial
    reference systems.

commit fd2adae3dc1635f883d810cce41a23b4436136c8
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Wed Jan 6 11:57:14 2016 +0100

    Bug#22343301: Error 1093 (HY000): You can't specify target table'.' for update
    
    In the problem query, a derived table is contained in the SET clause of
    the UPDATE statement. According to documentation, such derived tables
    should be materialized, in order to avoid error about updating a table
    that is also read in the same query.
    
    These two mechanisms are used to ensure proper handling:
    
    1. When resolving derived tables, exclude_from_table_unique_test is set
       so that materialized derived tables are excluded from later
       uniqueness test.
    2. unique_table() later performs the uniqueness test.
    
    After refactoring of derived tables in 5.7, exclude_from_table_unique_test
    is set later, when setup_fields() is called for update_value_list.
    But this is too late for unique_table() to notice it.
    
    The solution is to delay the call to unique_table() to after the
    derived tables are properly resolved. For single-table UPDATE, this
    means after setup_fields() has been called for update_value_list.
    For multi-table UPDATE, it means moving the test to
    Query_result_update::prepare(), just after setup_fields() has been
    called for *values.
    Notice also that since Query_result_update::prepare() is not called
    during query preparation, the uniqueness test has to be done twice.
    
    Some light refactoring has been made to Query_result_update::prepare(),
    to enhance locality of scope of local variables.

commit a8ec53e4c16eaa1e8b22059f6ae348df302dec60
Author: Debarun Banerjee <debarun.banerjee@oracle.com>
Date:   Wed Jan 6 12:45:42 2016 +0530

    Bug#21924224 POTENTIAL RUNNING OUT OF SPACE IN REDO
    
    Problem:
    --------
    The key issue is the margin calculation for foreground threads.
    If innodb_thread_concurrency = 0 (default), no margin for
    foreground threads are allocated. For small redo size and
    large write concurrency, concurrent threads loop and perform
    checkpoint to free redo space at mtr commit.
    
    If one of the mtrs is holding latch on the oldest modified page
    then checkpoint fails to create more space for redo and whole
    system hangs. It could also lead to redo overwrite eventually by
    repeated calls to checkpoint.
    
    Solution:
    ---------
    By current design we could avoid this scenario by reserving enough
    space for all running mtrs. However, currently it is not easy to
    arrive at correct foreground and background write concurrency
    and reserving too much space could have impact on existing use
    cases.
    
    We thus take the following approach to resolve the hang and
    reduce the possibility of redo overwrite.
    
    1. Change innobase_log_file_size minimum value from 1M to 4M.
    This would need documentation change.
    
    2. Correct length calculation log_margin_checkpoint_age() at mtr commit.
    
    3. AT mtr commit if not enough free margin attempt to do checkpoint once
    and continue.
    
    4. For write_always option don't overwrite redo log header with older lsn.
    
    Reviewed-by: Marko Makela <marko.makela@oracle.com>
    Reviewed-by: Pawel Olchawa <pawel.olchawa@oracle.com>
    
    RB: 10957

commit e72997d4af198f2d12ab06903ed0152abec420a1
Author: Benny Wang <benny.wang@oracle.com>
Date:   Wed Jan 6 03:18:07 2016 +0100

    Fixed bug#22195458: GCOLS: ASSERTION 0 AND CORRUPTION...
    
    There is a different setting on warning requirment when doing INSERT and
    SELECT.  When doing INSERT, server askes to throw warning. But for SELECT, it
    askes to ignore warning. Because of the inconsistence, the value of generated
    column can be evaluted into different value(e.g YEAR('a')).
    
    In order to keep the consistence, this patch makes YEAR value not to be
    related with the warning is required or not.
    
    There is a side effect after this patch. It will make YEAR('a') and
    YEAR('aaaa') return the same value '0000'.

commit f7b34194eec06c6be4d8326dec8231b09a283dcd
Merge: 96028b9 93a2e4f
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Jan 6 08:59:21 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 93a2e4f627748cefbbde530c189327146e752ce7
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Jan 6 08:58:15 2016 +0530

    Bug #22459137: MYSQL 5.6: VALGRIND FAILURES IN PB2 WITH
                   OPEN SSL TRACE
    
    Open ssl has valgrind issues. The relevant stacktraces have
    been added to valgrind.supp.
    
    This is a backport from 5.7:
    2ad2964fe0c254ee77c402b674befaa216f6cf20

commit 96028b9c6e453a22efcf2abf1701daa6b5fbf6dc
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Tue Jan 5 12:23:27 2016 +0100

    Bug#22176604: Wrong result on outer join with uncorrelated subquery, derived
    
    The problem may occur when we have a derived table that is used on
    the inner side of an outer join. The value of a column selected from
    such derived table is NULL if the outer join is null-complemented.
    We attempt to indicate this by pointing to the first table of the
    derived table and see if its null_row property is true. This strategy
    works fine for derived tables with a single table in it, but it may
    fail for multiple tables: A derived table which itself is an outer join
    may have tables with null_row = true, even though the derived table
    does produce a row (with null extension from the second table), or
    the tables are accessed in different order due to plan selection.
    
    It is the second case above that occurs here. The derived table is on
    the form t2 JOIN t3, but the plan is t3 - t2. In the regular case,
    this works. But sometimes when we have already completed a null
    extension for the same tables, the null_row property is on for a table,
    even though we have not yet checked the new rows.
    
    The solution to the problem is to reset the null_row property for
    a table just before returning from
    evaluate_null_complemented_join_record() after calling
    evaluate_join_record(). That way, the null_row property is always
    correct (it can only be true when we positively know that we
    have a null-extension for the inner tables of the outer join).
    
    As part of the fix, mark_as_null_row(TABLE *) is converted to a
    member function for struct TABLE and renamed to set_null_row().
    A corresponding function TABLE::reset_null_row() is also added, as well
    as a propery function TABLE::has_null_row().
    
    However, TABLE::null_row is still not made private. Some functions
    may take the address of this field, and we did not want to tamper
    with this property now.
    
    Join buffering is changed similarly: A call to TABLE::reset_null_row()
    is added in JOIN_CACHE::join_null_complements() just after calling
    generate_full_extensions(). However, no test case has been crafted
    to exercise this change.

commit 5e5e6ca67091a18e15884439e1a19807dcb2cb38
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Tue Jan 5 16:42:08 2016 +0800

    BUG#22469459 WRONG VALUES IN ADDED INDEX WHILE DROPPING VIRTUAL COLUMN
    
    It's a regression of BUG#22082762 RE-ENABLE SUPPORT FOR ADDING VIRTUAL
    INDEX WHILE DROPPING VIRTUAL COLUMN
    
    The root cause is that we use altered mysql table object to evaluate
    virtual column, the dict table is unchanged before commit. So the
    optimizer callback function cannot evaluate the virtual column value.
    
    The solutions is using old mysql table object for the evaluation.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11408

commit 5c2a342900a77544f1e4b20906006313803d1558
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Tue Jan 5 16:20:47 2016 +0800

    BUG#22469660 INNODB DOESN'T UPDATE INDEX STATS WHEN ADDING OR DROPPING
                 VIRTUAL COLUMN
    
    We skipped alter_stats_norebuild() when adding or dropping virtual column
    inplace, so the stats of added/dropped indexes in the alter will not be
    updated.
    
    The solution is dropping the table stats. The table stats will get rebuilt
    when it's opened next time.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11415

commit dd878c4b64bc06cebd6a6006be68b16c2b833a2c
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Tue Jan 5 08:14:45 2016 +0530

    Bug #22270139: SERVER CRASH WHEN TRYING TO COUNT THE
                   RESULTS OF A SUBQUERY USING FULLTEXT
    
    Post-push fix.
    
    A valgrind build is required to repro this issue.
    
    
    Issue:
    -----
    In a PREPARE statement, the "hints" object of every match
    function is initialized to a dummy value during the
    fix_fields phase. The hints object is not always deleted in
    the cleanup phase of the match function. It is freed along
    with the rest of the memroot at the end of the prepare.
    
    In the EXECUTE statement, the hints of the match function
    in the WHERE clause is re-initialized. The hints of select
    list's match function are not initialized since derived table
    has now been merged into the outer query block.
    
    So the select list's match function has a dangling pointer
    for hints.
    
    SOLUTION:
    ---------
    Currently hints are created on the runtime memroot. It
    should be created on the prepared statement memroot. This
    way it will be deleted only when the prepared statement is
    deallocated.

commit e84c3dba295e0b984c78b5ac4287fed5a334726e
Author: Mark Leith <mark.leith@oracle.com>
Date:   Mon Jan 4 13:41:26 2016 +0000

    Bug#21663578 INSTABILITY IN SYSSCHEMA.V_SCHEMA_TABLES_WITH_FULL_TABLE_SCANS
    
    Added wait conditions for the underlying performance schema data to be updated.
    
    Reviewed-by: Marc Alff <marc.alff@oracle.com>
    RB: 11407

commit 6f695524b3ac3cf431b1276cce595b1e76b6fca2
Merge: 8ca5ac4 14785bd
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Mon Jan 4 15:47:07 2016 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 14785bdb2a989492719b3cecafbc5b9c0c600589
Merge: 116bab1 b65c01d
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Mon Jan 4 15:46:34 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit b65c01d6a9ee2ccd637ae52fa5bbc7fdf701d8da
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Mon Jan 4 15:31:45 2016 +0530

    Description: yaSSL was only handling the cases of zero or
    one leading zeros for the key agreement instead of
    potentially any number.
    There is about 1 in 50,000 connections to fail
    when using DHE cipher suites.  The second problem was the
    case where a server would send a public value shorter than
    the prime value, causing about 1 in 128 client connections
    to fail, and also caused the yaSSL client to read off the
    end of memory.
    All client side DHE cipher suite users should update.
    Note: The patch is received from YaSSL people

commit 8ca5ac47c402fb620381be53b063c244bfe20030
Author: Pavan Naik <pavan.naik@oracle.com>
Date:   Mon Jan 4 15:28:46 2016 +0530

    BUG#22135383 : MYSQLTEST FAILS TO PROPERLY GROUP AN EXPECTED ERROR CLAUSE AND ITS QUERY
    
    Issue :
    =======
    When '--error an_expected_error' is separated from the following query merely
    by the beginning/end of if-{}-block mark, the expected error won't be counted
    by mysqltest.
    
    Fix :
    =====
    Add a check for 'if statement' and 'end of block' before clearing the array
    containing expected errors.
    
    Reviewed-by: Bjorn Munch <bjorn.munch@oracle.com>
    RB: 11025

commit a053720c905437d533bebd5b89c54f6670dfc21c
Author: Marko Mäkelä <marko.makela@oracle.com>
Date:   Tue Dec 29 17:19:41 2015 +0200

    Bug#20045167 UT_DELAY MISSING COMPILER BARRIER
    
    UT_RELAX_CPU(): Use a compiler barrier.
    
    ut_delay(): Remove the dummy global variable ut_always_false.
    
    RB: 11399
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>

commit f47717fd6d981fa29521cbec7f6fda2e7d1aafcb
Merge: f622bed 116bab1
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Dec 31 07:32:48 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 116bab1e51a762e6484d400120187bcfe86bf803
Merge: 36d85dd d6a208a
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Dec 31 07:32:05 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit d6a208adc1275aa005cd3707cd1b39713d288f12
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Thu Dec 31 07:31:12 2015 +0530

    Bug #21564557: INCONSISTENT OUTPUT FROM 5.5 AND 5.6
                   UNIX_TIMESTAMP(STR_TO_DATE('201506', "%Y%M"
    
    Issue:
    -----
    When an invalid date is supplied to the UNIX_TIMESTAMP
    function from STR_TO_DATE, no check is performed before
    converting it to a timestamp value.
    
    SOLUTION:
    ---------
    Add the check_date function and only if it succeeds,
    proceed to the timestamp conversion.
    
    No warning will be returned for dates having zero in
    month/date, since partial dates are allowed. UNIX_TIMESTAMP
    will return only a zero for such values.
    
    The problem has been handled in 5.6+ with WL#946.

commit f622bedfca5a5f63c75ad3eb5d77adcf442cb2ca
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Tue Dec 29 08:50:29 2015 +0100

    Bug#22338946 SEGFAULT IN LEX_ONE_TOKEN ON SOLARIS 12
    
    The server initializes all character set 'state maps' at boot time.
    If a character set is loaded from an XML file, we must initialize
    the 'state map' at run time.

commit 76d97081710aa887d9147e3387f5aa59cdd5b860
Merge: ebfa181 36d85dd
Author: Karthik Kamath <karthik.kamath@oracle.com>
Date:   Tue Dec 29 16:22:37 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 36d85dd96766282f144ec8ef68d877573775f356
Merge: f251868 d1678da
Author: Karthik Kamath <karthik.kamath@oracle.com>
Date:   Tue Dec 29 16:10:00 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit d1678da866eb6f543b0cc83990509fa3ba5d3707
Author: Karthik Kamath <karthik.kamath@oracle.com>
Date:   Tue Dec 29 15:58:44 2015 +0530

    BUG#21902059: "CREATE TEMPORARY TABLE SELECT ..." AND BIT(1)
                   COLUMNS
    
    ANALYSIS:
    =========
    A valgrind error is reported when CREATE TABLE .. SELECT
    involving BIT columns triggers a column type redefinition.
    
    In general the pack_flag is set for BIT columns in
    'mysql_prepare_create_table()'. However, during the above
    operation, redefined column types was handled after the
    special handling for BIT columns and thus pack_flag ended
    up not being set correctly triggering the valgrind error.
    
    FIX:
    ====
    The patch fixes this problem by setting pack_flag correctly
    for BIT columns in the case of column type redefinition.

commit ebfa181aa6fabb7d7391486084401bb5d62dce62
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Mon Dec 28 08:42:08 2015 +0100

    Followup: BUG#22082762 RE-ENABLE SUPPORT FOR ADDING VIRTUAL INDEX
              WHILE DROPPING VIRTUAL COLUMN
    
    Fix pb2 failure on werror builds.

commit aec158d0d781ad7ea05d4f881fab19d8732547e9
Author: Parveez Baig <parveez.baig@oracle.com>
Date:   Mon Dec 28 10:44:06 2015 +0530

    Bug #19071401 : BIG TESTS TIME OUT ON HUDSON: RPLMIXING_ENGINES AND RPLCRASH_SAFE
    
    The tests were getting timeout specially on windows due to many
    show_binlog_events.inc involved in the tests. All these tests will finally
    call rpl_mixing_engines.test which sources rpl_mixing_engines.inc file where
    the main operations are done and the File show_binlog_events.inc is called.
    
     Fix: Replaced the File show_binlog_events.inc with the query show binlog events
    with some column masking and the regex replacements needed for the tests result
    file to be same.
     Removed the include file big_test.inc from the rplmixing_engines tests as these
    tests are taking less time after the fix.

commit 3659fb3c766b55fbbc38f7dd0dbf6e8cd175b060
Author: Sergey Glukhov <sergey.glukhov@oracle.com>
Date:   Mon Dec 28 08:05:18 2015 +0300

    Bug#22186926: CONVERT_CONSTANT_ITEM(THD*, ITEM_FIELD*, ITEM**): ASSERTION `!RESULT' FAILED.
    
    Problem statement uses MAX/MIN optimization in opt_sum_query.
    Index access is used to check if optmization is possible and
    datetime column is not present in the index. So datetime field
    is unread after optmization. In convert_constant_item()
    incorrect value is obtained from the field since field is not
    evaluated. Attempt to store this incorrect value to the field
    later leads to assert failure.

commit c20aad8a6a72f3efa8e2c460a2c3406b77ea82fb
Merge: 846751e f251868
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Thu Dec 24 17:22:59 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit f2518688780bea3c89d6bda5229959f63792f959
Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
Date:   Thu Dec 24 16:39:33 2015 +0530

    Bug#21345391: ALTER TABLE ... CONVERT TO CHARACTER SET NOT EFFECT
                  AND REMAIN A TEMP TABLE
    
    Analysis:
    =========
    ALTER TABLE, CONVERT TO CHARACTER SET operation remains
    ineffective if
    a) Table contains only numerical data types.
    b) Algorithm used is INPLACE.
    Also the temporary '.frm' file created during the
    operation is not cleaned up.
    
    For the above ALTER TABLE operation, appropriate handler
    flag is not set, resulting in a no-op. Hence the operation
    remains ineffective and the CHARACTER SET is not altered.
    Also the temporary '.frm' file created was not cleaned up
    at the end of no-op.
    
    Note: The above operation for tables having character
    data types reports an appropriate error.
    
    Fix:
    ===
    a) Removed the ALTER_CONVERT flag used by parser
       to flag the CONVERT TO CHARACTER SET operation
       since it has similar use as that of ALTER_OPTIONS.
    b) ALTER_OPTIONS is now used to indicate the CONVERT
       TO CHARACTER SET operation as well.
    c) Added code to clean up the temporary '.frm' file
       created during no-op.

commit 846751e034a7912ceef37b82232fa01403053672
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Thu Dec 24 09:18:54 2015 +0800

    Followup: BUG#22082762 RE-ENABLE SUPPORT FOR ADDING VIRTUAL INDEX
              WHILE DROPPING VIRTUAL COLUMN
    
    Fix pb2 failure on windows & werror builds.

commit 00a83dc60c50e88d66f505ce8a28b9f5dd3948b7
Author: Andrei Elkin <andrei.elkin@oracle.com>
Date:   Thu Dec 10 14:23:02 2015 +0200

    Bug#21942487 	ASSERTION `STATIC_CAST<SQL_CMD_XA_COMMIT*>(THD->LEX->M_SQL_CMD)-> GET_XA_OPT()
    Bug#22273964 	INNODB: FAILING ASSERTION: TOTAL_TRX >= TRX_SYS->N_PREPARED_TRX
    
    **Problem description**
    
    An assertion of Bug#21942487
    
    static_cast<Sql_cmd_xa_commit*>(thd->lex->m_sql_cmd)->
                                  get_xa_opt() == XA_ONE_PHASE
    
    #8  0x0000000000e3a5e1 in ha_commit_low
    #9  0x00000000015158e6 in TC_LOG_DUMMY::commit
    #10 0x0000000001529bc3 in Sql_cmd_xa_commit::trans_xa_commit
    
    was caused by incorrect assumption by XA binlogging of wl6860 in
    that @@session.pseudo_slave_mode can be only set 1 through binlog.
    If fact the var can be set so manually.
    
    Another assert in Bug#22273964 takes place for the very same reason.
    
    **Solution**
    
    The most reliable way to identify that the executing thread
    is a binlog applier must include both the checking of rli_fake
    and @@session.pseudo_slave_mode.
    The former merely checking of the session variable as atttemp to
    identify the binlog applier is replaced by checking the conjuction
    of the two properties.
    
    Notice that load containting SET @@session.pseudo_slave_mode=1 and
    BINLOG '' pseudo-queries is not necessary authentic to mysqlbinlog output.
    Nevertheless it must be processable when it's manually engineered such way.
    A test is included to prove that as well.
    
    **Note**
    Beware of Bug #19502202 SERVER SHUTDOWN HANG SEEN IN SOME INNODB & RPL TESTS
    at testing with binlog.binlog_xa_prepared_disconnect that still fails sporadically.

commit 4d235e50cfa377253c00c5eccfff6c7f7dc8dd73
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Dec 23 13:43:04 2015 +0530

    Bug #22270139: SERVER CRASH WHEN TRYING TO COUNT THE
                   RESULTS OF A SUBQUERY USING FULLTEXT
    
    Issue:
    -----
    These issues occur under the following conditions:
    
    1) A derived table is merged into the outer query block.
    2) The same match function is used in the select-list and
       where clause of the derived table.
    
    The following are the problem areas:
    a) When a select count(*) without group-by is used in the
    outer-query, opt_sum_query tries to set the hints for the
    where condition. This is not allowed since, hints for slave
    (i.e., the where condition) are not accessed.
    
    But this where condition already has a master that has been
    set by the setup_ftfuncs. The result is an assert.
    
    b) While merging the derived table into the outer query,
    the fulltext function list is rebuilt. Only this time, the
    order of the functions is flipped. This creates a problem
    when deciding who-is-who's master. Since setup_ftfuncs
    expects the early expression to be the master of the later
    expression.
    
    Because of this, the ft-functions in select and where lists
     are eachother's master. The result is a recursion of the
    get_master function.
    
    
    SOLUTION:
    ---------
    sql/opt_sum.cc:
    Since the where condition is supplied to the opt_sum_query
    by default, setting hints should be done on the master.
    
    sql/sql_resolver.cc:
    Since we want the early-late expression order to be
    maintained, use push_back.
    
    sql/item_func.h:
    In case of prepare-execute statements, we need to set the
    master variable to NULL. This will be reset when the
    execute statement will call setup_ftfuncs.

commit 60359d9e0061351dc52660c8484fc84dc9587f26
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Dec 23 10:33:52 2015 +0800

    BUG#22082762 RE-ENABLE SUPPORT FOR ADDING VIRTUAL INDEX WHILE
                 DROPPING VIRTUAL COLUMN
    
    1. Enable adding virtual index on existing virtual column while
       dropping virtual column;
    2. Enable online adding virtual column with adding index;
    3. Skip uncommitted virtual index in purge when adding a virtual
       index on newly added virtual column.
    
    Reviewed-by: Marko Mäkelä <marko.makela@oracle.com>
    RB: 11357

commit e45702ba718a048466b42c0798f383b0405442e4
Merge: ab7c4ce 25432fa
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Tue Dec 22 22:38:34 2015 +0800

    Merge branch 'mysql-5.6' into mysql-5.7

commit 25432fa0c008afa4f545225b6f07cfba1837d475
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Tue Dec 22 22:07:13 2015 +0800

    BUG#22385442 - INNODB: DIFFICULT TO FIND FREE BLOCKS IN THE BUFFER POOL
    
    Problem:
    We keep pinning pages in dict_stats_analyze_index_below_cur(),
    but doesn't release these pages. When we have a relative small
    buffer pool size, and big innodb_stats_persistent_sample_pages,
    there will be no free pages for use.
    
    Solution:
    Use a separate mtr in dict_stats_analyze_index_below_cur(),
    and commit mtr before return.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11362

commit ab7c4ce6f5f88bde064f357ec5c88a99b1eeecc0
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Tue Dec 22 10:07:52 2015 +0100

    Bug#22321338 SELECTIVE INSTALL FOR DEVELOPMENT DOESN'T INSTALL ALL REQUIRED FILES
    
    Trying to install just the shared libraries, clients, and development support
    fails to install everything that is required.  After installing the
    "SharedLibraries", "Client", and "Development" components it should be
    possible to build a client application without errors, but this is NOT
    currently possible.
    
    Fix: add missing COMPONENT Development to binary_log_types.h

commit f1e9b4e26cc6064b22f5625081e2c78d0e4b21ba
Author: Catalin Besleaga <catalin.besleaga@oracle.com>
Date:   Tue Dec 22 12:04:26 2015 +0100

    WL9015: fix tests run with ps-protocol and query_cache

commit 5f1adbc05c4a7dfe55f63a1cbc5e4bd62f80b344
Author: Mark Leith <mark.leith@oracle.com>
Date:   Tue Dec 22 10:01:22 2015 +0000

    Merge branch 'mysql-5.7' into mysql-trunk
    
    (cherry picked from commit a3ee9fb5c5af8bae3677727128d719f9902b38d7)

commit 63427073e1ff0d7292aae0f7a3f43357a34b547a
Author: Mark Leith <mark.leith@oracle.com>
Date:   Tue Dec 22 10:00:07 2015 +0000

    WL#8993: Option to not log in the error log when unsafe statements are executed whilst using STATEMENT based binary logging
    
    Added a log_statements_unsafe_for_binlog option, which purely disables writing the unsafe statement warnings to the error log (warnings are still sent to the clients).
    
    Reviewed-by: Joao Gramacho <joao.gramacho@racle.com>
    Reviewed-by: Luis Soares <luis.soares@oracle.com>
    
    RB: 11076

commit e66ec0bbe185075fbbbdcd512a180e3995b7d796
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Tue Dec 22 14:00:47 2015 +0530

    Bug #22306581	VALGRIND FAILURE IN INNODB.TEMPORARY_TABLE
    
    	- Post push fix to address kevin's review comments.

commit e73fa025bac61e1c06d3f4a4c79a873c31881f2a
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Tue Dec 22 13:37:09 2015 +0530

    Bug #22070021	CHANGE VIRTUAL INDEX CALLBACK FUNCTION TO
    		AVOID THE UNINTENDED TABLE OBJECT.
    
    	- post push fix due to gcol_rollback testcase failure in embedded mode

commit 05f27190c7eb0d1b476eb3e67cdbff22aa06cfd0
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Tue Dec 22 08:00:10 2015 +0530

    Bug #22328395: REGRESSION: ?UNKNOWN COLUMN? FOR OUTER
                   COMPUTED VALUES USED INSIDE A SUBQUERY
    
    ISSUE:
    ------
    In the fix for Bug# 19823076, a subquery in the SELECT list
    was no longer allowed to refer to an alias of a column in
    the outer query.
    
    This was justified, since it was not supported by the
    standard sql syntax.
    
    SOLUTION:
    ---------
    Given that this is an extension used frequently, the
    restriction introduced in Bug# 19823076 is now removed.

commit a8801ce9a3236faa83616eb217538c8581bca6cd
Author: Kevin Lewis <kevin.lewis@oracle.com>
Date:   Mon Dec 7 15:01:46 2015 -0600

    Bug 22391925: INNODB: FIX UNNECESSARY TYPE CASTS IN I_S.CC
    mysql-5.7 cleanup changes suggested by Marko
    
    Calls to Field_longlong::store() using a ulint should use version
    store(longlong nr, bool unsigned_val)   instead of store(double nr)
    in order to avoid conversion to a double and back.
    
    Previously approved for mysql-trunk in rb#11021

commit bac9d63c9cc0e72b953e26676c660590959a7944
Author: Satya Bodapati <satya.bodapati@oracle.com>
Date:   Fri Dec 18 22:17:27 2015 +0530

    Bug#22179133 - INNODB: TOO SMALL BUFFER POOL FOR INNODB_PAGE_SIZE=64K
    
    Problem:
    --------
    When initializing rollback segment headers(max TRX_SYS_N_RSEGS), all
    rollback segment headers are accessed using single mtr.
    
    With buf_pool_size of 5M and innodb_page_size=64k,
    the maximum number of pages available is 80.
    When a single mtr accesses more than 80 pages, all the blocks
    are buffer fixed and cannot be replaced from buf pool.
    
    So we cannot find a free block.
    
    Fix:
    ----
    Access each rollback segment header in a separate mini-transaction.
    
    Reviewed-By: Marko Mäkelä <marko.makela@oracle.com>
    RB: 11367

commit b0922b111052cfea81daa7bc8b607a4e4cf109e7
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Mon Dec 21 15:28:19 2015 +0530

    Follow up fix to Bug#22016556
    
    Issue:
    =====
    The innodb_buffer_pool_load test fails in the weekly build for 32k and 64k
    page sizes.
    
    Fix:
    ====
    Make the data file autoextending in the testcase, which was
    pushed as part of Bug#21687636.
    
    Reviewed-by: Satya Bodapati <satya.bodapati@oracle.com>

commit 228f9c6a0dbb35bdc11b8a64d0cac74ba3402335
Author: Mauritz Sundell <mauritz.sundell@oracle.com>
Date:   Mon Dec 21 09:35:57 2015 +0100

    Bug#17400320 ALGORITHM= IS NOT SUPPORTED FOR ALTER TABLE WITH <PARTITION_OPTIONS>
    
    Fix test innodb.create_tablespace_partition failure on Windows introduced with
    
    commit 7b84d2d7282f0eb605934f714cad6d9204acc208
    Author: Mauritz Sundell <mauritz.sundell@oracle.com>
    Date:   Mon Nov 30 22:05:11 2015 +0100

commit ab036511840ceb7bf6e46a8a0be31f0318ba0c11
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Mon Dec 21 11:03:21 2015 +0530

    Bug #22070021	CHANGE VIRTUAL INDEX CALLBACK FUNCTION TO
    		AVOID THE UNINTENDED TABLE OBJECT.
    
    Problem:
    ======
    The crash occurs due to we use the wrong TABLE object for computing
    the virtual column. When a query uses multiple instances of the same table,
    the current code will pick one of the open table objects, possibly not the
    intended one.
    
    Solution:
    ========
    Change the interface for one of the call back functions
    that InnoDB uses to get virtual column values.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    Reviewed-by: Marko Mäkelä <marko.makela@oracle.com>
    RB: 11116

commit df1e24640d2605f7c3ba9cfc51a02bae89b172e8
Merge: 12f6cba 8a54f13
Author: Aditya A <aditya.a@oracle.com>
Date:   Fri Dec 18 23:56:53 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 8a54f1307e076e1c66786adb1efd7ad9ebd1519c
Author: Aditya A <aditya.a@oracle.com>
Date:   Fri Dec 18 23:54:05 2015 +0530

    Bug#20160327 OPTIMIZE TABLE REMOVES THE DATA DIRECTORY IN PARTITIONS
    
    Test case fix

commit 12f6cba1c32465c47d48a6e829d48ed08110d496
Author: Deepa Dixit <deepa.dixit@oracle.com>
Date:   Fri Dec 18 19:17:15 2015 +0530

    Bug#16988017 : *GROUP_COMMIT_DEADLOCK* TESTCASES ARE FAILING SPORADICLY ON FREEBSD9-X86-64BIT
    
    Re-enabling the disabled tests

commit 7b84d2d7282f0eb605934f714cad6d9204acc208
Author: Mauritz Sundell <mauritz.sundell@oracle.com>
Date:   Mon Nov 30 22:05:11 2015 +0100

    Bug#17400320 ALGORITHM= IS NOT SUPPORTED FOR ALTER TABLE WITH <PARTITION_OPTIONS>
    
    MySQL Cluster no longer support the keywords ONLINE and OFFLINE used
    with ALTER TABLE statements.
    
    Instead ALGORITHM=INPLACE and ALGORITHM=COPY should be used.  But
    for some partitioning commands it was not possible to specify
    ALGORITHM without syntax error.
    
    The commands that one can not specify ALGORITHM for is the ones
    that can not be combined with other commands within an ALTER TABLE
    statement.  Such as:
    
    ALTER TABLE table DISCARD TABLESPACE
    ALTER TABLE table IMPORT TABLESPACE
    ALTER TABLE table ADD PARTITION ...
    ALTER TABLE table DROP PARTITION ...
    ALTER TABLE table REBUILD PARTITION ...
    ALTER TABLE table OPTIMIZE PARTITION ...
    ALTER TABLE table ANALYZE PARTITION ...
    ALTER TABLE table CHECK PARTITION ...
    ALTER TABLE table REPAIR PARTITION ...
    ALTER TABLE table COALESCE PARTITION ...
    ALTER TABLE table TRUNCATE PARTITION ...
    ALTER TABLE table REORGANIZE PARTITION ...
    ALTER TABLE table EXCHANGE PARTITION ...
    ALTER TABLE table DISCARD PARTITION ...
    ALTER TABLE table IMPORT PARTITION ...
    
    Solution:
    
    The commands ALGORITHM=?, LOCK=?, and, WITH/WITHOUT VALIDATION, are
    identified as commands modifying the whole ALTER TABLE with no
    independent effect if stated by themselves.
    
    Support for these modifying commands are added so that they also
    can be stated *before* any of the above commands.
    
    Examples,
    ALTER TABLE t ALGORITHM=INPLACE, REORGANIZE PARTITION;
    ALTER TABLE t LOCK=SHARED, ALGORITHM=INPLACE, OPTIMIZE PARTITION p;
    
    Note that one can still not add these modyfing commands after these
    "standalone" commands.
    
    Note that this patch only allows ALGORITHM, LOCK, VALIDATION, to
    be parsed in combination with the above commands.
    
    No changes are made to any storage engine to support different
    uses of these modifying commands.

commit d2898fca9604a8dee45c1f2b17313206267de87c
Author: Catalin Besleaga <catalin.besleaga@oracle.com>
Date:   Mon Dec 14 17:08:42 2015 +0100

    WL#9015: added deprecation warnings for bitwise operations

commit d030c092429e759cf57eb336ef747bdf9ecb0408
Author: Dmitry Lenev <dmitry.lenev@oracle.com>
Date:   Fri Dec 11 11:00:44 2015 +0300

    WL#7567 "Handlerton MDL callback".
    
    Implemented support for notification of storage engines about
    acquisition and release of exclusive metadata locks, which allow
    metadata to be changed. Such support allows NDB SE to prevent
    concurrent changes to object metadata on different cluster nodes
    and opens path to implementation of proper cluster-wide metadata
    locking.
    
    Introduced new handlerton method which is called by MDL subsystem each
    time before X lock acquisition. This method gets MDL_key in order to
    be able to identify object on which lock is acquired. Lock acquisition
    can be refused by SE by returning error from this method. The same
    method (with a different notification_type argument) is called after
    release of X lock.
    
    Since in case of ALTER TABLE statement upgrade to X metadata lock
    happens late in the process of statement execution, it is expensive
    to abort statement execution as result of failed SE notification at
    upgrade time. To alleviate this issue we additionally notify SE at
    the start of ALTER TABLE on a base table and at its end. This gives
    SE chance to abort execution of ALTER TABLE early in the process
    without wasting precious resources.

commit ce148a6f781cc7aa8957755f0038278606ab049a
Author: Parveez Baig <parveez.baig@oracle.com>
Date:   Fri Dec 18 16:24:34 2015 +0530

    Bug #18890771: RPL.RPL_STM_MIXED_MTS_REC_CRASH_SAFE_SMALL NOT SUITABLE FOR PER PUSH RUNS
    
     Post Push fix. Changed random values in the test to the
     deterministic values.

commit a583e826d8f3beb0b5351e5ce6da427069af7f4f
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Thu Dec 17 19:33:47 2015 +0100

    Revert "WL#9015: added deprecation warnings for bitwise operations"
    
    Revert incomplete WL.

commit c8f436bdbaac2e57543e891ff7a10e1201a25c71
Author: Catalin Besleaga <catalin.besleaga@oracle.com>
Date:   Mon Dec 14 17:08:42 2015 +0100

    WL#9015: added deprecation warnings for bitwise operations

commit bce2f382d1ae19b8f9083b0d7fa86b874d737617
Merge: ff1c6fa 15a9f9c
Author: Aditya A <aditya.a@oracle.com>
Date:   Thu Dec 17 17:17:59 2015 +0530

    Bug#20160327	OPTIMIZE TABLE REMOVES THE DATA DIRECTORY IN PARTITIONS
    Merge branch 'mysql-5.6' into mysql-5.7
    [NUll Merge]

commit 15a9f9c46a428fa421471d89c0e28c7ee447b61d
Author: Aditya A <aditya.a@oracle.com>
Date:   Thu Dec 17 17:15:20 2015 +0530

    Bug#20160327	OPTIMIZE TABLE REMOVES THE DATA DIRECTORY IN PARTITIONS
    
    Post push failure fix

commit ff1c6fa9528d8461822e04b9d66dcf038d43d637
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Thu Dec 17 14:57:34 2015 +0530

    Follow up fix to bug#22016556
    
    Issue:
    =====
    The innodb_buffer_pool_load test fails when it is run with different page
    size option.
    
    Fix:
    ====
    Make the testcase, which was pushed as part of Bug#21687636, consistent
    among all the page sizes.
    
    Reviewed-by: Jimmy Yang <Jimmy.Yang@oracle.com>

commit bbed18024b2016eda0568427ea8960c381acf89c
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Thu Dec 17 11:27:08 2015 +0200

    Addendum to the fix for bug #21284761: fixed result files

commit 9872dab77f25a0209551fc9a1509e9462ffa7f3e
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Thu Dec 17 08:52:04 2015 +0530

    Bug#22286481 UNABLE TO START SERVER/CREATE DB WHEN SELINUX ENABLED WITH ENFORCING
    Bug#22314098 MYSQL 5.7 SERVER START FAILING AFTER INSTALLATION
    
    Due to SELinux policy mysqld can't read init-file located elsewhere than
    /var/lib/mysql. --initialize wants clean datadir.
    
    Move installing of validate password plugin to after initialize
    is done and use /var/lib/mysql as directory for init-file option.
    
    Use of other directory than /var/lib/mysql caused SELinux to deny
    access to file used as argument to --init-file. This broke initscript for
    new installations
    
    SELinux on Fedora don't accept access to /tmp for mysqld, use /var/tmp
    instead.

commit 41d6344a5b025c6668f858f840d4ee12f09fe419
Author: Dmitry Shulga <dmitry.shulga@oracle.com>
Date:   Thu Dec 17 08:51:23 2015 +0600

    BUG#22202665 - ADDING A TRIGGER TO A TABLE CHANGES THE BEHAVIOUR OF NULL DETECTION
    
    For non-strict mode attempt to implicitly insert NULL value into NOT NULL
    column led to a different results depending on whether trigger is set
    or not. Implicit insert means here the following use case:
      CREATE TABLE t1 (a INT, b INT NOT NULL);
      SET sql_mode= '';
      INSERT INTO t1 (a) VALUES (1);
    For such use case for mysql server before 5.7 the warning 1364
    "Field 'b' doesn't have a default value" was issued.
    In 5.7 the error 1048  "Column 'b' cannot be null" is issued.
    Such behaviour broke backward compatibility with 5.6.
    
    The reason for different behaviour in error handling of implicit NOT NULL
    constraint violation was that prior 5.7 checking for presense of all
    non-default values in INSERT statement was done before filling record
    by column values. So any attempt to INSERT a record without specifying all
    columns that doesn't have default values led to warning 1364. As of 5.7
    checking for presence of non-default values is done after record is filled and
    NOT NULL constraints has been already checked for ever table's field.
    This leads to the fact that error 1048 is issued instead of warning 1364.
    
    To fix the bug that broke backward compatibility checking for NOT NULL
    violation is done only for fields set during handling INSERT statement.
    In other words, for only those fields that is set in
    field->table->fields_set_during_insert checking for NOT NULL is done.

commit e7590ca391fa938ae891b39b8cfdda0d5ee965ed
Author: Abhishek Ranjan <abhishek.ar.ranjan@oracle.com>
Date:   Fri Dec 11 01:15:42 2015 +0530

    Bug#22313133 : STRICT SUBMODES MISSING IN SHOW CREATE TRIGGER
    
    Description:
    ------------
    
    This is a regression from Bug#18311187 and WL#8596 combined.
    
    Bug#18311187 introduced sub modes of STRICT mode, but only for
    use in syntax. They would have no effect on behaviour. To remove
    these sql modes completely in future, code was changed to not show
    these modes in SHOW CREATE TRIGGER statement.
    
    When WL#8596 added these sql modes back completely, this use case
    was missed to add back.
    
    Same case exists for Stored Procedure and Stored Function.
    
    Fix:
    -----
    Fixed code to show all sql modes in SHOW CREATE TRIGGER / PROCEDURE /
    FUNCTION statements.

commit 7925358c3c805a571333543635805627cce5f1c0
Author: Lukasz Kotula <lukasz.kotula@oracle.com>
Date:   Mon Dec 14 18:53:34 2015 +0100

    Bug#21966621: USAGE OF AUTO_RW_LOCK_READ/WRITE ON ALREADY LOCKED OBJECT CAUSES DEADLOCK
    
    Fault description:
    There is an internal fault in pthread that causes a deadlock when mysql_rwlock_rdlock, mysql_rwlock_unlock functions are used in wrong way. The faulty was triggered by calling two time lock function on already locked object, following seqence:
    pthread_rwlock_t *x;
    ...
    pthread_rwlock_wrlock(x);  // R:0
    pthread_rwlock_wrlock(x);  // R:EDEADLK
    pthread_rwlock_unlock(x);
    pthread_rwlock_unlock(x);  // Fault - pthread function doesn't check if the x object is still lock, it always decrement the lock-counter which causes an underflow
    
    pthread_rwlock_wrlock(x); // Deadlock - lock counter != 0
    
    The production code wasn't checking the result returned by locking function (EDEADLK, EINVAL) and it still was relasing mutex two times (RAII - destructor in object).
    
    Incorrect behaviour:
    The fault occured when pluging doesn't release the srv_session and leaves it to be released be server. When server is releasing the session its using Mutexed_map_thd_srv_session class to opearte on session list. Each method of this class is guarded by rwlock, thus function close_all_sessions_of_plugin_if_any() was calling Mutexed_map_thd_srv_session::do_for_all_matching (locking the mutex) and the callback was removing the session from the list by Mutexed_map_thd_srv_session::remove(second lock). Last call leaves the mutex in invalid state thus next attempt of accesing it will cause a deadlock.
    
    Fix description:
    The solution checks in constructor of Auto_rw_lock_read,Auto_rw_lock_write the result code mysql_rwlock_rdlock and if it wasn't locked then corresponding release function in destructor isn't called. The locking result could be also checked with assert to tell alert that the code is working wrongly.
    
    Reviewed-by: evgeny.potemkin@oracle.com
    RB: 10561

commit f72dcb86e08f93bd1fa9bad061a35c07f201abb1
Author: Lukasz Kotula <lukasz.kotula@oracle.com>
Date:   Mon Dec 14 18:13:23 2015 +0100

    Bug#21983102: CRASH AT PLUGIN UNLOAD (SERVER SESSION DEINITIALIZATION)
    
    Release of sessions in srv_session_deinit_thread is faulty, it iterates for all sessions while removing elements from the container.
    After removal iterator becomes invalid.
    
    Such sequence should reproduce the fault:
      srv_session_init_thread(..);
      srv_session_open(....);
      srv_session_deinit_thread();
    
    Incorrect behaviour:
    Thread_to_plugin_map::do_for_all_matching iterated through session list and the functor Remove_all_plugin_sessions was removing it from session list making iterators from do_for_all_matching invalid.
    
    Fix description:
    Method that executes a callback that was deleting session (Thread_to_plugin_map::do_for_all_matching) was changed to Thread_to_plugin_map::remove_all_of_plugin, which is deleting the objects directly.
    First it's making list of objects to be delated and then it iterates through it deleting objects from main list. Each list has its own iterators thus all are valid through whole process.
    
    Reviewed-by: evgeny.potemkin@oracle.com
    Reviewed-by: andrey.hristov@oracle.com
    RB: 10995

commit c05c2cf54132b926bcfb6607f25da8d6afc5e857
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Wed Dec 16 22:43:09 2015 +0530

    Bug#22374827 ALTER TABLE..LOCK NONE INVOLVING VIRTUAL COL IS REFUSED
    WITHOUT STATING A REASON
    
    Issue:
    ======
    InnoDB does not support online ALTER TABLE if the ALTER statement contains
    both ADD INDEX and ADD VIRTUAL COLUMN.
    
    When InnoDB refuses online operation (LOCK=NONE) due to this, it fails to
    specify a reason.
    
    Fix:
    ====
    In ha_innobase::check_if_supported_inplace_alter(),
    ha_alter_info->unsupported_reason is always set when setting online=false
    if the ALTER statement contains both ADD INDEX and ADD VIRTUAL COLUMN.
    
    RB: 11328
    Reviewed-by: Marko Mäkelä <Marko.Makela@oracle.com>
    Reviewed-by: Dmitry Lenev <dmitry.lenev@oracle.com>

commit 9d1f5636a67601b2c34980f764fa247abfd90a8b
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Wed Dec 16 21:44:53 2015 +0530

    BUG#20111575 ALTER TABLE...ADD SPATIAL INDEX...LOCK NONE IS REFUSED WITHOUT STATING A REASON

commit 69b66afd87e6c06368daf70804529b1c9c197490
Merge: 872360b 24b4841
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Wed Dec 16 19:12:12 2015 +0530

    Null Merge branch 'mysql-5.6' into mysql-5.7

commit 24b4841ce00ead5cff994a253bd047890619bbc1
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Wed Dec 16 18:58:53 2015 +0530

    Bug#22016556 INNODB LOOKS FOR BUFFER POOL FILE NAME IN '/' IF
    INNODB_DATA_HOME_DIR IS EMPTY
    
    Issue:
    ======
    If the server is started with the following parameter set in cnf file -
    "innodb_data_home_dir =", to specify absolute paths for the data files
    listed in the innodb_data_file_path value, then the server looks for the
    buffer pool dump file in the root directory and throws an error.
    
    Fix:
    ====
    The directory path of the buffer pool dump file is handled such that the
    server creates and looks for the buffer pool dump file at the right place.
    
    RB: 11081
    Reviewed-by: Satya Bodapati <satya.bodapati@oracle.com>
    Reviewed-by: Jimmy Yang <Jimmy.Yang@oracle.com>

commit 872360bcf681161329a09d4e27e6e8f625b88a18
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Thu Dec 10 14:44:02 2015 +0200

    Bug #21284761: DEFAULT_PASSWORD_LIFETIME SHOULD BE SET 0 AS IMPLICIT DEFAULT VALUE
    
    Changed the default from 360 (days) to 0 (indefinite).

commit ed4c1693411f0ab64a18a99700f4ea8b5f5f803a
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Wed Dec 16 17:07:15 2015 +0530

    Redirect the semanage message to /dev/null

commit 4f276ab3e7d6b04763999f3cb47cb7c94b33329e
Merge: 407d16c 14a59a6
Author: Aditya A <aditya.a@oracle.com>
Date:   Wed Dec 16 16:41:53 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 14a59a661e32e6c3f9f156f9bf0f6c8c631bf52e
Author: Aditya A <aditya.a@oracle.com>
Date:   Wed Dec 16 16:38:46 2015 +0530

    Bug#20160327    OPTIMIZE TABLE REMOVES THE DATA DIRECTORY IN PARTITIONS
    
    PROBLEM
    
    mysql-5.6+ uses inplace alter to do optimize table. Inplace alter was
    failing to update the create_info->data_file_name,because of which
    after optimize the ibd file was recreated in default path rather than
    the specified path.
    
    FIX
    
    Update the create_info structure in ha_partition::prepare_inplace_alter_table()
    
    [ Revewied by Kevin and Deb #rb11185 and #rb11267 ]

commit 407d16c2573c47a5c50fdafb95c854b99a54ff47
Author: Manish Kumar <manish.4.kumar@oracle.com>
Date:   Wed Dec 16 15:04:36 2015 +0530

    BUG#22318608 - ON A NORMAL SERVER 'START GROUP_REPLICATION' HITS ER3092, BUT WITHOUT ERROR LOG
    
    The problem with this bug was that the error reporting was done without
    actually printing any error in the error log.
    
    Added error reporting in the code to give proper error messages in case
    the server encounters any.

commit 71f58d923889e3c3274bd9b3e5ed38c9824d60fc
Merge: 7f89149 835d68b
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Wed Dec 16 12:12:55 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7
    
    Bug#22361702 - /USR/BIN/MYSQL-SYSTEMD-START DOES NOT RETURN CONTROL TO COMMAND LINE
    
    If the configuration files contains multiple datadir lines, use the last datadir
    entry in the RPM installation scripts

commit 835d68b100e5bc84e3f1464acfe14d49f3cfecf8
Merge: 9432f3a 8fdcb2b
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Wed Dec 16 12:09:01 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6
    
    Bug#22361702 - /USR/BIN/MYSQL-SYSTEMD-START DOES NOT RETURN CONTROL TO COMMAND LINE
    
    If the configuration files contains multiple datadir lines, use the last datadir
    entry in the RPM installation scripts

commit 8fdcb2b3fc6f573cad060661be00f7353edaf704
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Wed Dec 16 12:03:04 2015 +0530

    Bug#22361702 - /USR/BIN/MYSQL-SYSTEMD-START DOES NOT RETURN CONTROL TO COMMAND LINE
    
    If the configuration files contains multiple datadir lines, use the last datadir
    entry in the RPM installation scripts

commit 7f89149c0e32428b6cb0c7325fe4efd751b3bb6f
Merge: 08f9f09 9432f3a
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Wed Dec 16 10:51:42 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 9432f3a2daee6f76af7ba5ace7c13bfd57fbd8fc
Merge: 4356ed3 dffd85e
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Wed Dec 16 10:51:04 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6
    
    Null Merge

commit dffd85e1e76e5d1fd2baf1fecb62ac172e308dea
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Wed Dec 16 10:48:57 2015 +0530

    Bug#22278455: MYSQL 5.5:RPL_BINLOG_INDEX FAILS IN VALGRIND.
    
    Problem:
    =======
    rpl_binlog_index.test fails with following valgrind error.
    
    line
    Conditional jump or move depends on uninitialised value(s)
    at 0x4C2F842: __memcmp_sse4_1 (in /usr/lib64/valgrind/
    vgpreload_memcheck-amd64-linux.so)
    0x739E39: find_uniq_filename(char*) (log.cc:2212)
    0x73A11B: MYSQL_LOG::generate_new_name(char*, char const*)
    (log.cc:2492)
    0x73A1ED: MYSQL_LOG::init_and_set_log_file_name(char const*,
    char const*, enum_log_type, cache_type) (log.cc:2289)
    0x73B6F5: MYSQL_BIN_LOG::open(char const*, enum_log_type,
    
    
    Analysis and fix:
    =================
    This issue was fixed as part of Bug#20459363 fix in 5.6 and
    above. Hence backporting the fix to MySQL-5.5.

commit 2a9d2e5bae6407f8825028c525678664ea028517
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Tue Dec 15 22:12:14 2015 +0530

    Bumped up the version

commit f895926a3728b79312f004078b2ebbd2c823c1a7
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Tue Dec 15 16:47:57 2015 +0530

    Bug#22314098 MYSQL 5.7 SERVER START FAILING AFTER INSTALLATION
    
    Use of other directory than /var/lib/mysql caused SELinux to deny
    access to file used as argument to --init-file.
    This broke initscript for new installations
    
    SELinux on Fedora don't accept access to /tmp for mysqld, use /var/tmp
    instead.
    
    Change fixes bug#79442.

commit 08f9f099c986da7f52d3e07437f6c5da34c99c00
Author: Marek Szymczak <marek.szymczak@oracle.com>
Date:   Mon Dec 14 14:43:24 2015 +0100

    Bug#21458192 AUDIT API DOES NOT GENERATE EVENTS OF THE 'MYSQL_AUDIT_TABLE_ACCESS_CLASS' CLASS
    
    Post-push. Prevent generation of the table access events for non query
    open table function calls.

commit 10aabe76ae4639b31fdff766c0c80d607b6ee79d
Author: Norvald H. Ryeng <norvald.ryeng@oracle.com>
Date:   Fri Dec 11 09:21:17 2015 +0100

    Bug#22340858 CRASH AT GET_INTERVAL_VALUEITEMINTERVAL_TYPE
    
    Problem: Parsing the output of ST_GeometryType as a DATETIME value
    when the default character set is UTF32 causes the server to crash.
    
    Item_func_geometry_type::val_str_ascii() copies the hard-coded ASCII
    encoded name of the type into the result string, but claims that the
    character set is default_charset().
    
    The calling function expects an ASCII value and calls my_isdigit() on
    the result, which segfaults since treating the 4 byte character set as
    ASCII causes it to dereference a null pointer.
    
    Fix: Set Latin 1 as the character set of the return value from
    ST_GeometryType.

commit eb8c5836e20b121ca2d0f0a7b6d83a8e5f664158
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date:   Mon Dec 14 10:37:13 2015 +0100

    Bug#19031409 REVISIT WHAT HAPPENS IF ALLOCATION OF THE JOIN BUFFER FAILS
    
    Post-push fix, for a Valgrind-reported leak: the join cache's destructor
    doesn't free its buffer, so let's add an explicit freeing, when there was
    a previous OOM.
    In non-error conditions this is done by QEP_TAB::cleanup().

commit 82bae7c73f148876fc76a764a1a2ec51a227c3df
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Mon Dec 14 11:23:14 2015 +0100

    Bug#22223202: Query with double nested subquery much slower in 5.7
    
    In 5.7, we unconditionally merge a derived table or view reference
    into the outer query when possible and when not told otherwise
    by setting optimizer switch derived_merge=off.
    
    However, some queries with derived tables benefit from better
    performance when the subqueries are materialized. One such possible
    case is a derived table with dependent subqueries in the select list,
    used as the inner table of a left outer join. Such tables will always
    be read as many times as there are qualifying rows in the outer table,
    and the select list subqueries are evaluated for each row combination.
    The select list subqueries are evaluated the same number of times
    also with join buffering enabled, even though the table then only will
    be read once.
    
    Hence, applications may suffer from worse performance due to this.
    We will therefore revert some of the extra optimizations added in 5.7:
    Derived tables containing dependent subqueries in their SELECT list,
    will not be candidate for merging any more. We continue to merge
    derived tables with non-dependent subqueries, since such subqueries
    are executed only once, regardless of how many row combinations they
    are evaluated for.
    
    We should consider to re-enable this feature when we have implemented
    hints to directly impact whether to merge derived tables. We should
    also consider to improve the cost optimizer to calculate one set of
    plans with derived tables materialized and another set of plans
    with merging, and then pick the best of the best.

commit a586b795be49c59b3925f44a624e2a3437c8df31
Author: Bharathy Satish <bharathy.x.satish@oracle.com>
Date:   Mon Dec 14 12:37:21 2015 +0530

    Bug #22205360 ALTER USER/SET PASSWORD DO NOT WORK FOR --INIT-FILE EXECUTION
    
    SET PASSWORD/ALTER USER statements executed through --init-file fails.
    Problem is these sql statements executed as part of --init-file are executed
    as anonymous users which is not allowed. Provided a fix by allowing
    these statements to be executed only when server state is SERVER_BOOTING.

commit b83e3a151a049cada5db2d4bc01b3e137bfde4cf
Author: Bharathy Satish <bharathy.x.satish@oracle.com>
Date:   Mon Dec 14 11:59:06 2015 +0530

    Bug#22222013: ASSERTION `! IS_SET() || M_CAN_OVERWRITE_STATUS' FAILED
    IN ::SET_ERROR_STATUS
    
    Problem: When there are multiple parser errors there is an assertion.
    This is because in the existing code while copying parser diagnostic
    area DA to sql DA (not sure what wording to use for thd->m_stmt_da)
    we try to set the error status when there was already an error set
    which leads to assertion.
    Fix: Fix is to check if Da has error status or not and then only set
    the parser error.

commit bb66db8b342a0f57ba3de8bfb2f5a2524dc0501b
Author: Parveez Baig <parveez.baig@oracle.com>
Date:   Mon Dec 14 10:48:42 2015 +0530

    Bug#18890771: RPL.RPL_STM_MIXED_MTS_REC_CRASH_SAFE_SMALL NOT SUITABLE FOR PER PUSH RUNS
    
    RPL_STM_MIXED_MTS_REC_CRASH_SAFE_SMALL test is the smaller version of
    RPL_STM_MIXED_MTS_REC_CRASH_SAFE. This test was intended to run on pb2 for per
    push testing. The test was later disabled on pb2 as it takes too long to run.
    
     Fix: Reduced the test by introducing some amount of randomness in it. Four
    random variables have been implemented now. There are six while loops in test
    embedded one in another. The .inc file where the main operations are performed
    is sourced in the inner while loop. The test is reduced by calling the inner two
    while loops only if four random numbers matches with that of the corresponding
    four outer while loop variables. {result,query} log is disabled  for some
    operations which are sensitive to random variables. show_binlog_events.inc has
    been removed from the test. assert_binlog_events.inc is used to verify the
    sequence of events in binlog.

commit ae49a00101bb3033d4c77dde7e5d019b6d8f4d9e
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Sun Dec 13 07:53:26 2015 +0100

    5.7 modification for Valgrind suppression

commit 2ad2964fe0c254ee77c402b674befaa216f6cf20
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Sat Dec 12 11:56:46 2015 +0100

    Add suppression patterns on 5.7/trunk to fix Valgrind noise

commit 8b387c999aebd75ca3179506478a437e3d37761f
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Dec 11 18:08:51 2015 +0530

    Bug #22306581	VALGRIND FAILURE IN INNODB.TEMPORARY_TABLE
    
    Problem:
    =======
       Memory leaks exist when we create temporary compressed table and
    create compressed table in shared tablespace.
    
    Fix:
    ====
      Free the table object when creation of temporary compressed table and
    compressed table in shared tablespace fails.
    
    Reviewed-by: Marko Mäkelä <marko.makela@oracle.com>
    RB: 11298

commit 9a71cbea00d2f0dd4fe50f5014ac1fe15a14577d
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Thu Dec 10 16:27:24 2015 +0100

    Bug#22320154 VALGRIND SUPPRESSION NEEDED FOR LIBSTDC++ 5
    
    Valgrinding any testcase on Ubuntu 15.10 give 'reachable errors'
    Add suppressions, these are known not to be deleted.

commit e348909d7f1336374c3abaeb12f3ca0aa3ee4b99
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Thu Dec 10 16:26:04 2015 +0100

    Bug#21458192 AUDIT API DOES NOT GENERATE EVENTS OF THE 'MYSQL_AUDIT_TABLE_ACCESS_CLASS' CLASS
    
    Post-push fix: valgrind error in generate_table_access_event
    when it calls is_ps_or_view_context_analysis

commit 2dbbe6da1e33ce834a3523f357a33c2ab37f0ff9
Author: Maria Couceiro <maria.couceiro@oracle.com>
Date:   Wed Oct 28 18:24:42 2015 +0000

    BUG#21915239 SLAVE-PRESERVE-COMMIT-ORDER SHOULD GENERATE ERROR WHEN LOG-BIN IS DISABLED
    
    Problem:
    slave-preserve-commit-order only works when the binary log
    and log-slave-updates are enabled. However, there was no
    error in the slave's error log when slave-preserve-commit-order
    is enabled and the binary log or log-slave-updates are
    disabled when initializing the slave.
    
    Fix:
    Since enabling slave-preserve-commit-order only makes sense
    in an MTS scenario, with this patch, an error is printed in
    the slave's error log when a multi-threaded slave is initialized
    if slave-preserve-commit-order is enabled and either the binary
    log or log-slave-updates are disabled. The slave is still able to
    initialize with the new error message in the error log but it
    will be unable to start because this will also issue an error
    (the latter error was already implemented before this patch).
    This patch does not add any error on the master server, which is
    still able to initialize and start normally even if the slave has
    this incompatible configuration.

commit bbc343fd94a83578d59386f93b270d470aaee7a0
Author: Sergey Glukhov <sergey.glukhov@oracle.com>
Date:   Wed Dec 9 10:05:30 2015 +0300

    Bug#22132822 CRASH IN GROUP_CHECK::IS_FD_ON_SOURCE
    
    Item_field::table_ref is NULL for generated column.
    The fix is to use table from Field object for GC.

commit 06c66b806dd622107edd2351e00974742c9c1e81
Author: Marek Szymczak <marek.szymczak@oracle.com>
Date:   Wed Dec 9 00:17:07 2015 +0100

    Bug#21458192 AUDIT API DOES NOT GENERATE EVENTS OF THE 'MYSQL_AUDIT_TABLE_ACCESS_CLASS' CLASS
    
    Problem
    =======
    Audit API defined events of the 'MYSQL_AUDIT_TABLE_ACCESS_CLASS' class were not generated.
    
    Solution
    ========
    Following events of the 'MYSQL_AUDIT_TABLE_ACCESS_CLASS' class are generated during execution of
    the listed queries:
    
    - MYSQL_AUDIT_TABLE_ACCESS_READ
      - SELECT
      - INSERT ... SELECT (table referenced in the SELECT clause)
      - UPDATE ... WHERE (tables referenced in the WHERE clause)
      - REPLACE ... SELECT (tables referenced in the SELECT clause)
      - HANDLER ... READ
    - MYSQL_AUDIT_TABLE_ACCESS_INSERT
      - INSERT
      - INSERT ... SELECT (table referenced in the INSERT clause)
      - REPLACE
      - REPLACE ... SELECT (table referenced in the REPLACE clause)
      - LOAD DATA INFILE
      - LOAD XML INFILE
    - MYSQL_AUDIT_TABLE_ACCESS_UPDATE
      - UPDATE
      - UPDATE ... WHERE (table or tables referenced in the UPDATE clause)
    - MYSQL_AUDIT_TABLE_ACCESS_DELETE
      - DELETE
      - TRUNCATE
    
    Queries executed from stored procedures or triggers generate exact table access events
    as executed separately.
    Execution of the prepared statement generate events depending on the content of the statement.
    Every event of a given subtype for a table is generated only once during a single query
    or subquery.
    
    Table access event generation does not reflect real I/O operation on a given table. Events are
    generated before the tables are being accessed. Events are also generated, when no real table
    access takes place, but there was intention to do so during preparing tables before the
    execution takes place.
    
    Events are not generated for temporary tables, views, information schema and performance
    schema tables.
    
    Reviewers
    =========
    Marc Alff <marc.alff@oracle.com>
    Ramil Kalimullin <ramil.kalimullin@oracle.com>

commit 04bd6c1c324095b048536b3158c28b9895a6d25b
Author: Daogang Qu <bill.qu@oracle.com>
Date:   Thu Dec 10 08:25:29 2015 +0800

    Bug#21895421  DEBUG ASSERT AFTER 'SET GTID_MODE' DURING PRECOMMIT OF GTID-VIOLATING STATEMENT - post fix
    
    The rpl_set_gtid_mode_on_after_implicit_pre_commit.test is failing
    on PB2 daily trunk, due to it is verifying a DEBUG ASSERT and
    using a debug sync point.
    
    To fix the failure, source have_debug.inc and have_debug_sync.inc
    in the test script.

commit 5d206fe3645aac2dd6c2063c6e0b57b88ad20973
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date:   Tue Dec 8 13:47:59 2015 +0100

    Bug#22133710 GCOLS: READ UNCOMMITTED: ASSERT !TABLE || (!TABLE->WRITE_SET || BITMAP_IS_SET(TA
    
    Problem: in READ UNCOMMITTED isolation, a SELECT reading an indexed
    generated column could trigger an assertion failure in debug binaries.
    
    my_eval_gcolumn_expr*() is called by the storage engine, which may request to
    evaluate more generated columns than read_set/write_set says.
    For example, InnoDB's row_sel_sec_rec_is_for_clust_rec() reads the full
    record from the clustered index and asks us to compute generated columns
    that match key fields in the used secondary index. So we trust that the
    engine has filled all base columns necessary to requested computations,
    and we ignore read_set/write_set.
    The in_purge branch becomes unneeded.
    I noticed that the my_rec argument of innobase_get_computed_value()
    is always NULL, so in agreement with Jimmy I remove it.

commit b2f1734be339850fd3b602996ef951b919cf6274
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date:   Fri Nov 27 09:43:05 2015 +0100

    Bug#22268110 VIEW USING HEXADECIMAL OR BIT LITERAL GIVES WRONG RESULTS
    
    Printing of hex/bit literals was limited to the last 8 bytes.
    As this code is used for writing the definition
    of views and generated columns to the data dictionary,
    a view or generated column could produce unwanted results.
    The query printed by EXPLAIN (in the warning line) was
    also affected.

commit 3ba77fbd82374b7d707a99fd097d5287b0fbcf50
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date:   Tue Dec 8 09:39:43 2015 +0100

    Bug#19031409 REVISIT WHAT HAPPENS IF ALLOCATION OF THE JOIN BUFFER FAILS
    
    Doc: "an out-of-memory failure in join buffer allocation could lead
    to wrong results for multi-table queries".
    
    Some code was trying to gracefully handle OOM in join buffer allocation,
    and it was tested in i_main.join_cache. But the result in that test
    was actually incorrect (one excess row). Fixed the relevant code:
    now, instead of trying to still use the already-allocated buffers of
    previous tables in the join order (which led to wrong results due to
    dependencies between the buffers), it disables them all.
    Note that in this unlikely scenario, the query will not necessarily get
    the same query plan as when join buffering is disabled before optimizing
    the query.  The cost calculations would be different, and index
    selection/join order might be different.  Hence, the query plan may be
    far from optimal if one is not able to create join buffers.

commit d1bfc16a86fc199aa6687366d957c96030b92afc
Author: Satya Bodapati <satya.bodapati@oracle.com>
Date:   Mon Dec 7 22:17:04 2015 +0530

    Bug#22311319 - SERVER CRASHES ON INVALID VALUE FOR VARIABLE INNODB_SAVED_PAGE_NUMBER_DEBUG
    
    Problem:
    --------
    The debug variable is used to dirty a page in a tablespace.
    When the variable is set to non-existent page, it causes
    innodb to crash
    
    Fix:
    ----
    Dirty the page of tablespace after checking the size of tablespace.
    
    Reviewed-By: Marko Mäkelä <marko.makela@oracle.com>
    RB: 11248

commit 011d6417888260e51902d77f4c52e26b37a6c7ee
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Tue Dec 8 18:10:42 2015 +0530

    Bug# 22321041:  INNODB_ZIP.4K AND INNODB_ZIP.8K TESTS ARE FAILING ON PB2 WEEKLY-5.7
    
    WL 8196 post test fix.

commit fd6b7ae8d6ecdc027237fa5ce132325b4f36aa90
Author: Deepthi Eranti_Sreenivas <deepthi.e.s@oracle.com>
Date:   Tue Dec 8 15:38:52 2015 +0530

    Bug#22084462:MYSQL TEST BINLOG.BINLOG_ROW_MIX_INNODB_MYISAM FAILS
    
    Reason for failure:
    The test case uses a subtest '/extra/binlog_tests/mix_innodb_myisam_binlog.test'.
    Here,in the test for BUG#7947 section,it is creating some temporary tables using
    connection 'con2' and then closing this connection and observing that the
    'DROP TEMP TABLE' statements were properly binary logged.
    It fails with a Result Content Mismatch because, on issuing the disconnection of
    "con2", the test case does not wait until the server cleanup the thread for that
    connection before updating the binary log events.
    
    Fix:
    Included include/assert_binlog_events.inc which waits for the binlog events and
    also assert that the temporary tables were dropped.
    
    'extra/binlog_tests/mix_innodb_myisam_binlog.test' subtest is used
    in 'binlog_row_mix_innodb_myisam.test' and 'binlog_stm_mix_innodb_myisam.test'
    Result files for both these tests('binlog_row_mix_innodb_myisam.result'
    and 'binlog_stm_mix_innodb_myisam.result') are updated.
    
    In include/assert_binlog_events.inc,the description of $slave_timeout
    did not specify the unit of time.
    
    Fix: Changed the decription in 'Usage' of assert_binlog_events.inc.

commit d356e3c930950fe19b397b90c876615c9d6b04ec
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Tue Dec 8 08:41:12 2015 +0100

    Bug#22239474: Fix failing tests

commit bfcb8d5602834697a202bddaf0c192209365514b
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Mon Dec 7 16:35:29 2015 +0100

    Bug#22239474: Unexpected error 1093 on nested subquery for update
    
    Problem:
    After it was made possible to merge derived tables into the outer
    query block, it was no longer possible to use a documented workaround
    for how to avoid error ER_UPDATE_TABLE_USED when referencing the same
    table in a subquery as was used as target for an UPDATE or DELETE
    statement.
    
    The solution is to put tighter control over which derived tables that
    can be merged. A boolean property is introduced in class SELECT_LEX,
    controlling which derived tables underneath it that can be merged:
    The important derived tables to control are those immediately
    underlying some subqueries of an UPDATE or DELETE statement.
    
    Notice that this property affects unnamed derived tables only;
    view references are not affected.

commit 96c9d6d06f001fec78fe2a3110662e700192b509
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Tue Nov 24 10:26:44 2015 +0100

    Add man pages for lz4_decompress and zlib_decompress to rpm spec files.
    
    (cherry picked from commit c8b8d60dd4fca296dbdc607fd2a73c04ad13dc5c)
    
    Conflicts:
    	packaging/rpm-fedora/mysql.spec.in
    	packaging/rpm-oel/mysql.spec.in
    	packaging/rpm-sles/mysql.spec.in

commit ff97cfac214ac768bb3c16191d474f252a000773
Merge: ebdd239 eb634e0
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Dec 7 14:59:43 2015 +0100

    Merge branch 'mysql-5.7.10-release' into mysql-5.7
    
    Conflicts:
    	packaging/deb-wily/mysql-common.install
    	packaging/rpm-fedora/mysql.spec.in
    	packaging/rpm-oel/mysql.spec.in
    	packaging/rpm-sles/mysql.spec.in

commit ebdd239f0fc0d818eb58b0d121803ce05309e4a1
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Fri Mar 20 04:34:19 2015 +0100

    Disable some rpl.*mixing* tests that fail too often on PB2 weekly
    
    Bug#19071401 BIG TESTS TIME OUT ON HUDSON: RPL*MIXING_ENGINES* AND RPL*CRASH_SAFE*
    
    Approved by Anitha Gopi <anitha.gopi@oracle.com> over IM.
    
    (cherry picked from commit 73d6c628559a069ebcb3afe11ccc4f8d882e30e8)

commit 2c0acabbeedc7678958f34baf37c190d61c5578a
Merge: 0d1690a 4356ed3
Author: Hery Ramilison <hery.ramilison@oracle.com>
Date:   Mon Dec 7 13:05:15 2015 +0100

    Upmerge of the 5.6.28 build

commit 4356ed36c3e641ffc2fbb4894c2bdccd7aee42ba
Merge: 51100e1 6bc30f8
Author: Hery Ramilison <hery.ramilison@oracle.com>
Date:   Mon Dec 7 13:03:54 2015 +0100

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

commit 0d1690a7da601c45100deaf843d2d34e86177bc5
Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
Date:   Mon Dec 7 15:28:41 2015 +0530

    Bug #22293530 INCORRECT NUMA-SPECIFIC CODE IN BUF_CHUNK_INIT()
    
    Problem:
    
    The size information passed to the mbind() call in buf_chunk_init()
    function was incorrect.
    
    Solution:
    
    Pass correct size information to the mbind() call in function
    buf_chunk_init().
    
    approved by Jimmy over IM.

commit bf050ecc5c80f72ad068b0228324bebed9064def
Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
Date:   Mon Dec 7 12:40:49 2015 +0530

    Bug #22293511 INCOMPLETE NUMA SUPPORT ON BUFFER POOL RESIZING
    
    Problem:
    
    While doing buffer pool resize, the NUMA memory policy was not set
    to MPOL_INTERLEAVE.
    
    Solution:
    
    When doing buffer pool resize, set the NUMA memory policy to
    MPOL_INTERLEAVE.
    
    rb#11231 approved by Jimmy.

commit 52deff9c1dc2d7807f4aeb875b8cab8cbaa893a9
Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
Date:   Mon Dec 7 10:44:23 2015 +0530

    Bug #21950756 INNODB: FAILING ASSERTION: !(&DICT_SYS->MUTEX)->IS_OWNED()
    IN DICT0STATS.CC 3049
    
    Post push fix.  Since the test innodb.cmp_per_index uses compressed table,
    the innodb page size must not be greater than 16k. So including the
    page size check have_innodb_max_16k.inc.
    
    approved by jimmy over IM.

commit f21a88440ea9b0f41d1f8965f73e0e5417c7e463
Merge: ee65f30 51100e1
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Sun Dec 6 01:13:37 2015 +0530

    Null Merge branch 'mysql-5.6' into mysql-5.7

commit 51100e123401952f74f8a61aef5cac31a2d45ef0
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Sun Dec 6 01:12:24 2015 +0530

    Bug #21762319	ADDING INDEXES ON EMPTY TABLE IS SLOW
    		WITH LARGE INNODB_SORT_BUFFER_SIZE.
    Problem:
    =======
    Adding index on empty table is slow when innodb_sort_buffer_size
    is large.
    
    Fix:
    ====
    Delay the temporary file creation for alter table operation
    will lead to avoid the file creation for empty table.
    
    Reviewed-by: Marko Mäkelä <marko.makela@oracle.com>
    RB: 11200

commit ee65f30b5faf2eefdafa4fd876ed56e8f59567ed
Author: Dyre Tjeldvoll <Dyre.Tjeldvoll@oracle.com>
Date:   Thu Nov 12 14:32:56 2015 +0100

    WL#8927: Deprecate mysql_plugin in 5.7 and remove in 5.8
    
    On mysql-5.7: Emit deprecation warning when mysql_plugin is used
    and update test result files accordingly.
    
    On mysql-trunk: Remove source files, CMake entries, test files, result files
    and references in packaging scripts.

commit 4a4bda158f1c0fbba9913b7e4668654eee0dec4c
Merge: ee95aa3 d8b50c2
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Fri Dec 4 18:57:34 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit d8b50c2b8ed01d4b840dd409a381c6b82f35b7f8
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Fri Dec 4 18:55:38 2015 +0530

    Bug #22216715 IN-CONSISTENT ERROR MESSAGES NOTICED WITH SSL AND WITHOUT SSL UNDER
    
    Post push changes

commit ee95aa3604ec555e2a2aae25d72002e7004a05df
Merge: 21087e5 8f6e4f5a9
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Fri Dec 4 17:33:23 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 8f6e4f5a9832b1b3905e1caccf474d9c7371abf8
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Fri Dec 4 17:18:14 2015 +0530

    Bug#21631855: HANDLE_FATAL_SIGNAL (SIG=11) IN FT_BOOLEAN_CHECK_SYNTAX_STRING |
                  FT_PARSER.C:92
    
    DESCRIPTION
    ===========
    Starting the server with default charset as 'utf16le', and
    setting system variable "ft_boolean_syntax" results in
    server crash.
    
    ANALYSIS
    ========
    Function "ft_boolean_check_syntax_string()" uses the MACRO
    "my_isalnum" which checks for the member "ctype" of the
    default charset. Since this member is NULL (for charset
    'utf16le') therefore when accessed, results in SEGFAULT!
    
    We can prevent it altogether by replacing "my_isalnum"
    (which depends on the default charset) with C's "isalnum()"
    . Using "isalnum()" here is sufficient as the input to this
    function is guaranteed to be in ASCII format.
    
    FIX
    ===
    Replaced user defined "my_isalnum" with C's "isalnum()"
    in the function "ft_boolean_check_syntax_string()"

commit 21087e51a91ebb0ff8b4c15d90e5800b0902753f
Author: Daogang Qu <bill.qu@oracle.com>
Date:   Fri Dec 4 09:16:51 2015 +0800

    Bug#21895421 DEBUG ASSERT AFTER 'SET GTID_MODE' DURING PRECOMMIT OF GTID-VIOLATING STATEMENT
    
    Problem:
    
    A DBUG assert failure happened when changing GTID_MODE to
    ON/ON_PERMISSIVE and/or ENFORCE_GTID_CONSISTENCY to ON
    from OFF right after the ongoing GTID-violating statement
    causes to implicitly commit the previous transaction.
    
    Analysis:
    
    Some statements violate GTID consistency and therefore cannot be
    logged using GTIDs. Therefore, such statements are disallowed in
    the following cases: C1. enforce_gtid_consistency=ON, or C2.
    GTID_MODE=ON/ON_PERMISSIVE and GTID_NEXT=AUTOMATIC, or C3.
    GTID_NEXT=UUID:NUMBER. ENFORCE_GTID_CONSISTENCY and GTID_MODE are
    dynamic, but cannot be set to values that would make GTID-violating
    statements invalid in case there are ongoing GTID-violating
    statements. Therefore, to keep track of ongoing GTID-violating
    statements we maintain global counters of ongoing GTID-violating
    statements. A GTID-violating statement has three possible side
    effects: S1. generate an error (in case any of C1-C3 applies) S2.
    generate a warning (in case none of C1-C3 applies and
    enforce_gtid_consistency=WARN) S3. increase the GTID-violation
    counter (in case none of C1-C3 applies) If a GTID-violating
    statement has an implicit pre-commit, it was implemented such
    that S1 is done before the pre-commit and S2+S3 are done after
    the implicit pre-commit. The reason for this is: - S1 is before
    the pre-commit because it prevents the pre-commit from happening
    at all. - S3 is after the pre-commit because the counter is
    decremented on commit, and therefore if the counter was incremented
    before the implicit pre-commit, it would be immediately decremented,
    so the counter would not be effective for the duration of the
    statement. However, this opens up a race condition. After the
    GTID-consistency check for S1 has passed, and before the check for
    S2+S3 is done, it is possible to change GTID_MODE and/or
    ENFORCE_GTID_CONSISTENCY so that the check does not pass. That
    means the statement will execute, even if it is supposed to
    generate an error. This causes a debug assertion.
    
    Fix:
    
    It is fine that the error in S1 does not prevent the implicit
    pre-commit from happening, since users expect GTID-violating
    DDL statement to implicitly commit the previous transaction
    before executing it and we did the same thing in S2 and S3.
    All the logic (S1+S2+S3) can be moved until after the
    implicit pre-commit.

commit 9c8c0ecf6c5cbf094dcfdadd060e4c9a4e71f25b
Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
Date:   Thu Dec 3 10:42:05 2015 +0530

    Bug #21950756 INNODB: FAILING ASSERTION: !(&DICT_SYS->MUTEX)->IS_OWNED()
    IN DICT0STATS.CC 3049
    
    Problem:
    
    When the information schema table information_schema.innodb_cmp_per_index
    is queried, an in-memory heap table is dynamically created and required
    data is populated.  The data is collected from the dictionary and populated
    in the heap table.  When the heap table becomes larger then it is converted to
    an on-disk InnoDB intrinsic temporary table.
    
    When the information is collected from data dictionary and populated in the
    in-memory heap table the dict_sys->mutex is taken.  This mutex will be released
    when the heap table is completely populated.  When the transition happens from
    in-memory heap table to on-disk InnoDB intrinsic temporary table, the
    dict_sys->mutex is being held.  So when the InnoDB intrinsic temporary table
    is created the dict_sys->mutex is being held.  This causes the assert.
    
    Solution:
    
    Before creating the InnoDB intrinsic temporary table release the
    dict_sys->mutex.  Reacquire the dict_sys->mutex after creating the InnoDB
    intrinsic temporary table.
    
    rb#11106 approved by Bin Su and Marc Alff.

commit cef61585ce90e2790a162cfcfef16ca870d94247
Author: Knut Anders Hatlen <knut.hatlen@oracle.com>
Date:   Wed Dec 2 17:34:58 2015 +0100

    Bug#22089623: ASSERTION IN ITEM_FUNC_TRIG_COND::VAL_INT() WITH SUBQUERY
                  ON LEFT SIDE OF IN
    
    Problem:
    
    If the left expression of an IN expression is a row subquery that does
    not access any tables, an assertion could be raised in debug builds,
    and wrong results could be returned in release builds.
    
    The assert failure was introduced by the fix for bug#20729351, but the
    wrong results were seen even before that fix.
    
    Analysis:
    
    The root cause for these problems is an inconsistency in how
    nullability is represented. For Item_row, the maybe_null flag tells if
    any of the columns in the row could be NULL. For scalar subqueries and
    row subqueries represented by Item_singlerow_subselect, maybe_null has
    this meaning:
    
    - If the subquery is scalar, maybe_null == true means that the
      returned column could be NULL, or that the subquery could return an
      empty result (which would make the scalar subquery evaluate to
      NULL). This is consistent with how maybe_null is used in Item_row.
    
    - If the subquery returns multiple columns (a row subquery) and it is
      not a UNION, maybe_null == true means that the subquery could return
      empty results. And, conversely, maybe_null == false means that it
      could not return empty results. It does not say anything about the
      nullability of the columns. This is not consistent with how
      maybe_null is used in Item_row and in scalar subqueries.
    
    - If the subquery is a row query that is a UNION, maybe_null == true
      means that it accesses tables, whereas maybe_null == false means
      that it does not access any tables.
    
    Take these two equivalent statements:
    
      SELECT (NULL, NULL) IN ...
    
      SELECT (SELECT NULL, NULL) IN ...
    
    In the former, the Item_row that represents the left operand of the IN
    expression, has maybe_null == true. In the latter, the
    Item_singlerow_subselect that represents the left operand, has
    maybe_null == false.
    
    Or take these two equivalent statements:
    
      SELECT (SELECT 1, 2 WHERE FALSE) IN ...
    
      SELECT (SELECT 1, 2 WHERE FALSE UNION SELECT 1, 2 WHERE FALSE) IN ...
    
    In the former of these, the Item_singlerow_subselect has maybe_null ==
    true. In the latter, maybe_null is false.
    
    These inconsistencies confuse the code that transforms IN expressions
    to EXISTS expressions in the following way:
    
    Item_in_subselect::row_value_transformer() sets up a data structure
    (pushed_cond_guards) that might be needed in the synthetic predicates
    that are created later. It only does this if left_expr->maybe_null is
    true. However, the data structure is needed if any of the values in
    the left expression could be NULL, and this is not what
    left_expr->maybe_null tells us if left_expr is an
    Item_singlerow_subselect, only if it is an Item_row.
    
    Because of this, it might skip setting up pushed_cond_guards even
    though it will be needed later. When it is attempted used later, and
    it is found that it is NULL, it results in an assertion failure or a
    wrong result.
    
    Before bug#20729351, all the columns returned by the row subquery
    (represented by Item_cache objects) had maybe_null set to false, even
    if the value could be NULL. This was clearly wrong, and it caused
    wrong results in some cases. The assert wasn't seen, though.
    
    After bug#20729351, all the columns returned by the row subquery have
    maybe_null pessimistically set to true. This made the queries take a
    slightly different code path, which still produced wrong results, but
    now also raise an assert failure.
    
    Solution:
    
    This patch fixes these problems by making the maybe_null flag in
    Item_singlerow_subselect have a value that is more consistent. Now it
    is false if and only if we know for sure that it is never going to
    return empty results, and none of the returned columns are nullable.
    
    It also makes the maybe_null flag of the individual columns in the row
    subquery more accurate. Instead of being always false/true as they
    were before/after 20729351, the maybe_null flag now tells the actual
    nullability of the column (if the column could have the value NULL, or
    if the subquery could return an empty result, maybe_null is true).
    
    Additionally, testing of this fix exposed another, earlier wrong
    result regression, caused by "WL#6369: EXPLAIN for other thread." A
    query such as
    
      SELECT (SELECT 1, 2 UNION SELECT 1, 2) IN (SELECT 1, 2)
    
    started returning 0 instead of 1 after WL#6369, and it started raising
    an assert failure after bug#20729351.
    
    The problem is very similar to bug#22090717, in that the optimization
    of the IN expression happens earlier now than before. It tries to read
    the values returned from the UNION subquery before the subquery has
    been evaluated. The patch enhances the fix for bug#22090717 with an
    extra check in Item_in_subselect::mark_as_outer() to prevent reading
    of data from a subquery before the subquery has been evaluated, except
    in the case where the subquery returns a basic constant (a literal).

commit 12c95645758bb66d5c9932676e7aa911c6a22f3e
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Wed Dec 2 22:23:31 2015 +0100

    Declare two XA tests as experimental.
    
    Approved over IM by Anitha Gopi <anitha.gopi@oracle.com>

commit 485a269f757aaaeee57fdf8b7b0378eaa55c7620
Merge: a4d2f3e cdc72eb
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Thu Dec 3 10:27:57 2015 +0800

    Merge branch 'mysql-5.6' into mysql-5.7

commit cdc72eb113d93b9148c92cdfe84859f8644a3f6e
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Dec 2 12:14:52 2015 +0800

    BUG#22291765 INSERT A TOKEN OF 84 4-BYTES CHARS INTO FTS INDEX
                 CAUSES SERVER CRASH
    
    we allow max token size up to 84 in both MyISAM and InnoDB, but
    we suppose max multiple-bytes char length is 3 bytes, which is
    not true. We support 4 bytes chars, e.g. in utf8mb4. So inserting
    a token of 84 4-bytes chars will cause server crash.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    Reviewed-by: Xing Zhang <xing.z.zhang@oracle.com>
    RB: 11210

commit a4d2f3ebc729bfd339f2176ae732e15990d7ded3
Author: Knut Anders Hatlen <knut.hatlen@oracle.com>
Date:   Fri Nov 27 15:54:37 2015 +0100

    Bug#22278524: ALTER TABLE SOMETIMES CONVERTS TEXT TO JSON WITHOUT
                  SYNTAX CHECKING
    
    If ALTER TABLE changes the type of a JSON column to TEXT with
    character set utf8mb4 and collation utf8mb4_bin (the same character
    set and collation as the JSON type has), it does not convert the
    existing column values from JSON binary format to JSON text format.
    Instead, the resulting column values will contain the raw binary
    representation of the original JSON values.
    
    If the type is changed in the opposite direction, the same thing
    happens, with the result that the JSON column contains text data
    instead of binary data. Subsequent attempts to access the column
    values will raise an error because the JSON binary parser doesn't
    understand JSON text format.
    
    This patch makes Copy_field::get_copy_func() pick do_conv_blob()
    instead of do_copy_blob() when copying between JSON and non-JSON
    types. This ensures that the values are properly converted between the
    different formats, and not just copied byte by byte.

commit 373dd2249f750d29cdf28a974259ef6d90111cff
Merge: 3ce6f55 53ed26c
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Dec 2 11:39:24 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 53ed26cca73cddf1bedb5fff2ab45aa7428af3e0
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Wed Dec 2 11:37:18 2015 +0530

    Bug #17883203 : MYSQL EMBEDDED MYSQL_STMT_EXECUTE RETURN
                    "MALFORMED COMMUNICATION PACKET" ERROR
    
    Description :- C API, "mysql_stmt_execute" fails with an
    error, "malformed communication packet", even for a simple
    query when prepared statments are used with libmysqld.
    
    Analysis :- The packet size specified in
    "emb_stmt_execute()" [libmysqld/lib_sql.cc] and "execute()
    [libmysql/libmysql.c] should be consistent across libraries
    (libmysqld/libmysql) because "mysql_stmt_execute()"
    [sql/sql_prepare.cc ] is being called from both functions
    depending upon the libaries (libmysqld/libmysql) used.
    Currently the packet size used in "emb_stmt_execute() is 5
    and in "execute()" is 9. When the C API,
    "mysql_stmt_execute", is executed from an application which
    is linked with libmysqld, it fails in the function
    "mysql_stmt_execute()" because of incorrect packet size.
    Another bug also exists in the "Protocol::net_store_data()"
    [libmysqld/lib_sql.cc] due to dereferencing an undefined
    "next_field" pointer which results in a segmentation fault.
    
    Fix:-
    (a)The packet size is made consistent across libmysqld
    and libmysql.
    (b) For the problem found internally:
    Functions "prepare_for_resend(), "net_store_data()" (with
    and without charset conversion) are defined seperately for
    Protocol_binary class in case of embedded library.

commit 3ce6f55c8c8a6f31b10c035443f239a3c01f570b
Author: Daogang Qu <bill.qu@oracle.com>
Date:   Wed Dec 2 12:34:04 2015 +0800

    Bug#21452916  SILENT FAILURE TO START IF MYSQL.GTIDS_EXECUTED GETS HA_ERR_LOCK_WAIT_TIMEOUT
    
    If a server is crashed after preparing a XA transaction and right before
    committing the XA transaction, which is used to modify the system
    gtid_executed table explicitly by users, then the following recovery
    is aborting due to an innodb_lock_wait_timeout error when it is
    reading the system gtid_executed table.
    
    To fix the problem, we do not allow users to modify the
    mysql.gtid_executed table explicitly by a XA transaction.

commit eab008347ff343bf0a0311cd47a744b55269c64d
Merge: 824794e 6b5f401
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Dec 2 10:33:22 2015 +0800

    Merge branch 'mysql-5.6' into mysql-5.7

commit 6b5f401dcbb1ab38ad9224b7df8aa17283a55ba7
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Dec 2 10:16:40 2015 +0800

    BUG#21922532 SERVER CRASH WITH FTS QUERY IN HIGH CONCURRENCY
    
    The root cause is that we access memory 'in_fts_query' of a MYSQL TABLE
    after it's closed.
    
    The solution is removing 'in_fts_query' reset in innobase_fts_close_ranking().
    because we have already reset the flag when closing TABLE before cleanup.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11183

commit 824794e45981b306dee9d97ccb2dd6d420b5998f
Author: Bin Su <bin.x.su@oracle.com>
Date:   Wed Dec 2 09:54:11 2015 +0800

    BUG#22256752 - PURGE THREAD DIES: FAILING ASSERTION: COL_LEN - 8 > 1 ||
    LEN < 256
    
    To store blob data, we would check the max blob data length according to
    blob type, for example, TINYBLOB requries 1 byte to store the length,
    and 255 bytes for the data itself, and BLOB requires 2 bytes for length, etc.
    
    Under this constraint, to get the computed BLOB for virtual column,
    we always pass a buffer with fixed length according to row format,
    this is OK for BLOB, but not OK for TINYBLOB. Thus it results in the
    failing assertion.
    
    The fix is that we should create and pass a buffer of proper length for
    all kinds of BLOBs, to support TINYBLOB, we just need a buffer of 255 bytes.
    
    RB: 11197
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>

commit 598aafd7cb075946ae0ca881acb045e3e2e6392a
Author: Horst Hunger <horst.hunger@oracle.com>
Date:   Tue Dec 1 15:03:00 2015 +0100

    removed parallel for hudson joib on Solaris to be successful

commit 4d42cd552efd0ae0752042d4ef98dd3f9dfc74b9
Author: Marc Alff <marc.alff@oracle.com>
Date:   Tue Dec 1 10:47:50 2015 +0100

    Bug#22291560 PREPARED STATEMENT INSTRUMENTATION CRASHES
    
    Under some combination of consumers,
    the prepared statement instrumentation could crash the server.
    
    The root cause is using a pointer, that was not initialized
    for an edge case code path.
    
    The fix is to always initialize the member
    PSI_statement_locker_state::m_statement
    in the statement instrumentation.

commit 07cc4149228c9284f174b2121acc388836483da5
Merge: 521467e 31480c0
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Dec 1 15:39:09 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 31480c0cc6854d95b918bf9335bee58221d18820
Merge: 06ba430 5705fd9
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Dec 1 15:38:37 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 5705fd9b642db8cf58d9105314905c191a3cab9f
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Dec 1 15:38:11 2015 +0530

    Bug#21205695	DROP TABLE MAY CAUSE SLAVES TO BREAK
        Problem:
        ========
        1) Drop table queries are re-generated by server
        before writing the events(queries) into binlog
        for various reasons. If table name/db name contains
        a non regular characters (like latin characters),
        the generated query is wrong. Hence it breaks the
        replication.
        2) In the edge case, when table name/db name contains
        64 characters, server is throwing an assert
        assert(M_TBLLEN < 128)
        3) In the edge case, when db name contains 64 latin
        characters, binlog content is interpreted badly
        which is leading replication failure.
    
        Analysis & Fix :
        ================
        1) Parser reads the table name from the query and converts
        it to standard charset(utf8) and stores it in table_name variable.
        When drop table query is regenerated with the same table_name
        variable, it should be converted back to the original charset
        from standard charset(utf8).
    
        2) Latin character takes two bytes for each character. Limit
        of the identifier is 64. SYSTEM_CHARSET_MBMAXLEN is set to '3'.
        So there is a possiblity that tablename/dbname contains 3 * 64.
        Hence assert is changed to
        (M_TBLLEN <= NAME_CHAR_LEN*SYSTEM_CHARSET_MBMAXLEN)
    
        3) db_len in the binlog event header is taking 1 byte.
           db_len is ranged from 0 to 192 bytes (3 * 64).
           While reading the db_len from the event, server
           is casting to uint instead of uchar which is leading
           to bad db_len. This problem is fixed by changing the
           cast type to uchar.

commit 521467e63906eb9289218d1e86fc19e77f6c5133
Author: Benny Wang <benny.wang@oracle.com>
Date:   Tue Dec 1 04:34:43 2015 +0100

    Fixed bug#22179637: INSERT INTO TABLE FROM SELECT ACCEPTS TO INSERT INTO
    GENERATED COLUMNS
    
    In current version, miss to constraint generated columns assignment to be only
    DEFAULT value for INSERT...SELECT statement. This patch provides such a check.

commit ad992c5ad10ed0e2418b61a0f193130c06bb4a83
Author: Benny Wang <benny.wang@oracle.com>
Date:   Tue Dec 1 04:23:06 2015 +0100

    Fixed bug#21980430: GCOLS: CRASHING
    
    DS-MRR works in the following way: 1) Use a secondary handler to scan the
    index to collect the row_ids. 2) Sort the row_ids in a buffer. 3) Use the
    original handler to scan the rows according to the sorted row_ids. In step
    1), the virtual generated columns will be updated if they exist in read_set
    because step 1) uses a covering index to collect the row_ids but ignores to
    change the read_set. Because the base columns of generated columns are not
    filled in step 1), the valgrind warnings are thrown during evaluate the
    virtual generated columns.
    
    There are two possible solutions: 1) Set a temporary read_set for the
    secondary index scan. In the temporary read_set, we only need set the
    row_id column. After DS-MRR is done, we can restore the read_set.
    2) Set table->key_read to be TRUE when doing the secondary scan and
    restore it after having read the index using the second handler. If
    table->key_read is set to be TRUE, during evaluating virtual generated
    columns, the server finds it's a covering index scan and the evaluation
    of virtual generated columns will be skipped (Details can be referenced
    in function update_generated_read_fields).
    
    This patch chooses 2) because it's simpler than 1).

commit afaf845263462ff8b41c712212fd6b0b3e2bfb43
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Thu Oct 29 12:21:23 2015 +0100

    Bug#22078874 GIS FILES IN SQL/ TAKE UNACCEPTABLY MANY RESOURCES TO COMPILE
    
    Problem: Some of the gis source files take long time to compile,
    and require lots of memory.
    
    Solution:
    Remove template argument CoordinateElementType from BG_models.
    It is always double anyways.
    
    Move templatized code out of item_geofunc_internal.h
    add explicit template instantions.
    
    (cherry picked from commit 32f1278485bf0791ae1bec7c287109e93222c9a0)
    
    Conflicts:
    	libmysqld/CMakeLists.txt
    	sql/CMakeLists.txt
    	sql/item_geofunc_internal.h
    	sql/item_geofunc_setops.cc
    	sql/spatial.cc
    	sql/spatial.h

commit 4edf064b6d3e2b928d80753239c11ad210c7a642
Merge: c0e9dbd 06ba430
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Mon Nov 30 17:03:42 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 06ba43030b42962457a7ad53d345b30d289fe1f2
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Mon Nov 30 16:47:08 2015 +0530

    Bug #22216715 IN-CONSISTENT ERROR MESSAGES NOTICED WITH SSL AND WITHOUT SSL UNDER UCS2 CHARSET
    
    Description: In-consistent error messages noticed when we use
    ssl and non-ssl connections with unsupported client
    charsets(like "utf32","utf16","ucs2")
    
    Analysis: When the client sends the initial packet for the
    connection setup, it will send the client charset number
    along with the protocol packet. The server receives and
    parses it through parse_client_handshake_packet(). In that
    before establishing the SSL connection it will try to
    validate the client charset and notices that the client
    charset is not supported and returns the error. But since
    the connection request is sent by the ssl client it will
    receive the charset error message and parses it in his
    own way and gives the error as
    "protocol version mismatch[2026]".
    
    Fix: Moved the client charset validation function
    init_client_charset(), after the ssl connection handshake.

commit c0e9dbd4efbe8a90f9f570ca89c4100c6cb7c066
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Sat Nov 28 18:40:43 2015 +0530

    Bug#21914047 SHOW CREATE DUMPS AFTER ALTER ON INNODB TABLE WITH PARTITIONS
    USING TABLESPACE
    
    Issue:
    ======
    The current issue is with default table space mentioned at table level.
    
    ALTER TABLE ADD COLUMN moves all the partitions to the default tablespace
    for the table regardless of what tablespace each partition is said to
    belong to during the creation of the table. This causes mismatch between
    part_info->tablespace (from frm) and dict_table_t causing the assert.
    
    Also, another issue found here is that, ALTER TABLE t1 TABLESPACE ts1 moves
    all the partitions to the tablespace ts1, which is correct but
    part_info->tablespace still points to the old tablespace again hitting the
    assert.
    
    Fix:
    ====
    For ALTER TABLE ignore the TABLESPACE clause in create option for existing
    partitions.
    
    RB: 10584
    Reviewed-by: Kevin Lewis <kevin.lewis@oracle.com>
    Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com>

commit a6e7b4d1d72585535594777256c6fe56569d1a56
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Mon Nov 30 10:33:38 2015 +0100

    Bug #22213873: MYSQLD --INITIALIZE SHOULD ALLOW IRRELEVANT
          CONTENT (E.G. LOST+FOUND) IN DATADIR
    
    Post-push fix: broken build
    sql_initialize.cc:284:10: error: auto changes meaning in C++11; please remove it [-Werror=c++0x-compat]

commit ae153e6cb4ddce2430f7ad2a362f3a9900ecf781
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Mon Nov 30 10:22:12 2015 +0200

    Bug #22213873: MYSQLD --INITIALIZE SHOULD ALLOW IRRELEVANT
      CONTENT (E.G. LOST+FOUND) IN DATADIR
    
    Reused the --ignore-db-dir list for the files in the database
    directory being created by --initialize.
    Now --initialize considers the data directory empty if all
    it has is entries starting with "." or  entries that match
    inside --ignore-db-dir list.
    
    Had to move the initialization of the list before the datadir
    creation to support that.
    
    Added a test case.

commit 114fbf6d0d6ff8e6e1986368db79dab7dc25cf69
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Mon Nov 30 13:39:25 2015 +0530

    Bug #21508627	ASSERTION: MODE == 16 || MODE == 12 || !FIX_BLOCK->PAGE.FILE_PAGE_WAS_FREED
    
    Problem:
    =======
    From 5.7, a transaction can use multiple rollback segments.
    
    DMLs on temporary tables go to non-redo rollback segment
    DMLS on normal tables  go to  redo rollback segment
    
    Undo log processing is done via priority queue. After selecting a trx_no
    and the corresspoding rollback segments used by transaction, we process
    rollback segments sequentially.
    
    In this bug scenario:
    
    (1)Transaction trx1 deals with noredo segments for first few undo_no's.
       and redo segments for remaining undo_no's. trx1 undo_nos for nonredo
       segment are lesser than undo_no's from redo segment
    
       For example take this scenario:
    
       trx1:
       uses non redo rollback segment from undo_no 1 to  10 (segment uses space_id: 21)
       uses redo rollback segment from undo_no    11 to 100 (segment uses space_id: 0)
    
    (2)Purge processing for trx1 started by processing all undo records
       present in redo segment. (i.e we purge until undo_no 100 and make
       limit->undo_no = 100)
    
    (3) When we reach rseg_truncate_frequency is reached, we will start undo truncate.
    
    (4) Undo truncation process all rollback segments and frees the undo pages or segments.
    
       (i)segment is freed when undo trx_no for segment < limit->trx_no (this indicates all
       undo pages of a trx are purged).
    
       (ii)undo log pages are freed when undo segment trx_no == limit->trx_no and undo_page->max_undo_no
       (last rec undo_no) < limit->undo_no. (this indicates only some undo pages of trx are purged)
    
    (5) In our example, undo truncation sees that limit->undo_no = 100 and thinks everything upto undo_no 100
       can be truncated. So it also frees pages belonging to non redo rollback segment
       (undo_no 1 to 10 < limit_undo_no 100) But we haven't purged non-redo rollback segment yet.
    
    (6)Purge resumes now and tries to process non-redo rollback segment which has just been freed by
       undo truncation and accessing freed undo page causes the assert failure.
    
    Fix:
    ===
    When freeing(undo truncation of) undo pages, free only if space_id of rollback segment
    matches with limit->space_id. This is the way to avoid the way to free not-yet purged pages.
    
    Reviewed-by: Satya Bodapati <satya.bodapati@oracle.com>
    Reviewed-by: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    RB: 11055

commit e040ef09b9e9dc63946bf2497bf39127ec18ea79
Merge: 5f747dd 37cc253
Author: Joao Gramacho <joao.gramacho@oracle.com>
Date:   Sat Nov 28 13:40:41 2015 +0000

    Merge branch 'mysql-5.6' into mysql-5.7

commit 37cc25391236054b08d1d92737736c5d9b26cdc1
Author: Joao Gramacho <joao.gramacho@oracle.com>
Date:   Sat Nov 28 12:36:45 2015 +0000

    BUG#22245619 SERVER ABORT AFTER SYNC STAGE OF THE COMMIT FAILS
    
    This is a post-push fix.
    
    Reverted the previous changes and made the binary log sync to use the
    MY_IGNORE_BADFD flag when calling mysql_file_sync(). This flag will make
    the sync procedure to ignore bad file descriptor errors, so the issue
    will not be considered an error anymore.

commit 5f747dd804cedefb9d33731d5aafb4aa7948ec52
Merge: 47da353 ce7bf82
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri Nov 27 18:02:23 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit ce7bf820dfccc8dda3ccd74ab544d9731734c9d9
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri Nov 27 18:01:33 2015 +0530

    Bug#21317739: APPLYING CREATE TEMPORARY TABLE SQL ON A
    SLAVE WITH REPLICATE-REWRITE-DB FAILS
    
    Fixing a post push test issue.

commit 47da353a4f7cf06e5738ccdd3eea78ca5d428d71
Merge: ea58aa7 a535f68
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri Nov 27 13:48:16 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit a535f68440d9b980fb30164a78bc17de8db5ea23
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Thu Nov 26 18:40:34 2015 +0530

    Bug#21317739: APPLYING CREATE TEMPORARY TABLE SQL ON A SLAVE
    WITH REPLICATE-REWRITE-DB FAILS
    
    Problem:
    =======
    As part of fix for BUG#16290902, at the time of writing the
    'DROP TEMPORARY TABLE IF EXISTS' query into the binlog, the
    query will not be preceded by a 'use `db`' statement. The
    query will have a fully qualified table name.
    
    Eg:
    'USE `db`; DROP TEMPORARY TABLE IF EXISTS `t1`;'
    will be logged as
    'DROP TEMPORARY TABLE IF EXISTS `db`.`t1`;'.
    
    Because of this change application of 'replicate-rewrite-db'
    filter rule will fail on slave, as it works only on default
    database specified in 'use' statement. This causes slave to
    break when the 'CREATE TEMPORARY TABLE' is re-executed on
    slave.
    
    Analysis:
    ========
    The intention of BUG#16290902 fix was to address a specific
    scenario where the default database does not exist on the
    slave but in spite of that DROP TEMPORARY TABLE IF EXITS
    query will be binlogged with 'USE default_db' statement.
    Which causes point in time recovery to fail when user uses
    Slave's binary log to re-apply. But the fix that was more
    generic. It completely removed 'USE default_db' for DROP
    TEMPORARY TABLE IF EXITS queries even when they have their
    default databases present. Hence the scope of the fix should
    have been narrowed.
    
    
    Fix:
    ===
    At the time writing 'DROP TEMPORARY TABLE IF EXISTS' query
    into the binary log, check if the default database exists.
    If it exists then write 'USE default_db' in the binary log.
    If default database is not present then log the query with
    qualified table name.

commit ea58aa72b62ee7eae589aea982c6800260d36837
Merge: 370558e 81bd49d
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 26 21:56:59 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 81bd49d30b63d0e28786a69374835c8b00ea7c6e
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 26 21:49:00 2015 +0530

    Bug #19688135 ASYMMETRIC_ENCRYPT: UNINITIALIZED VALUE WHEN CHECKING FOR "PRIVATE KEY"
    Description:
    Valgrind warning "Conditional jump or move depends on uninitialised value(s)" noticed when
    a encrypt function is executed along with concat() function having a null string(i.e concat('',a))
    
    Analysis:
    In Item_func_concat::val_str() when we have "res2->length() == 0" we just "continue".
    And 'Ptr' string is not having the null terminated character. Hence valgrid is reporting the
    Warning(like conditional jump .... ) when the 'Ptr' string is used in function asymmetric_encrypt()
    through strstr() api. Where as in case of res2->length() > 0 we call res->append(*res2) and
    we append '0' to the 'Ptr' string. So, valgrind is happy that the string is properly null terminated.
    
    Also we also noticed that get_algo() and get_digest_mode() has similar issues.
    
    Fix:
    used my_memmem() which has size of the string arguments, instead of strstr().
    And to fix get_algo(), get_digest_mode() issues we null terminated the input string because my_memmem will work only for case sensitive strings.

commit 370558e5b03d6a538dcf69953ec0c98b32d9dd90
Author: Joao Gramacho <joao.gramacho@oracle.com>
Date:   Tue Nov 17 09:54:08 2015 +0000

    BUG#22125441 VALGRIND ERROR ON RPL.RPL_4THREADS_DEADLOCK
    
    Problem:
    
    A replication test case started failing on PB2 valgrind without any
    change in the server code around the reported issue.
    
    Analysis:
    
    First of all, PB2 probably started reporting the issue because of the
    use of a newer version of valgrind or compiler, as the code involved
    in the reported issue wasn't changed.
    
    The valgrind report stated that a "conditional jump or move depended on
    uninitialized value" while comparing two arrays of chars using memcmp.
    
    The code that initializes one of the arrays used in the comparison is
    setting only its first element as zero, letting the remain of the array
    uninitialized.
    
    Fix:
    
    The issue was fixed by initializing the whole array with zeros.

commit d4ce6b4225153bf57af3578e96954a17883829c3
Merge: a4c7097 324a19b
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Thu Nov 26 20:12:23 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 324a19b85684d0bbb92545b48e666b9caa05cd01
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Thu Nov 26 20:11:38 2015 +0530

    BUG#19286708 REPLICATION BROKEN AFTER CREATION OF SCHEDULED EVENTS
    
    Problem: In mixed replication, events that has unsafe functions
    (sysdate()) cannot be created.
    
    Analysis: DDL Statements (that change metadata) are always
    getting written in the binlog in STATEMENT format irrespective
    of binlog_format settings. And the changes to the metadata
    should not be replicated as the same statement when it is executed
    on Slave will update the metadata on slave side. Event based SQL
    commands (CREATE EVENT, ALTER EVENT and DROP EVENT) belong to
    the same category. Code was written to take care of changing the
    current_statement_binlog_format into 'statement' if it is 'row'
    in case of executing/replicating such statements. But in case of
    create event and alter event, after we are converting row format
    to statement format, while we are opening the tables server decides
    the binlogging format (in decide_binlog_format()) and the logic
    again changes binlog format to "row" if it sees the statement is
    unsafe and we are using mixed format.
    
    Fix: Reset the thd.variables.binlog_format to 'statement' before create/alter
    events work when we are clearning current_statement_binlog_format.
    And set it back to the original value at the end of the work.

commit a4c7097e2a87684bcb0affaf6cce1fce28b9df37
Merge: dcde8c0 f1b8a70
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Thu Nov 26 14:04:29 2015 +0100

    Merge branch 'mysql-5.6' into mysql-5.7

commit f1b8a70aa6ed2add67952e48ae7043ed535c8e7a
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Thu Nov 26 13:52:51 2015 +0100

    Bug#22194831 INSTALL-SOURCE AND INSTALL-WIN-SOURCE CONTAIN OUTDATED INFORMATION
    
    Post-push fix: Remove references to INSTALL-BINARY

commit dcde8c00317693156e6bdd371d2769bd4c496ef5
Author: Tatiana Azundris Nuernberg <tatjana.nuernberg@oracle.com>
Date:   Thu Nov 26 11:28:26 2015 +0000

    Bug#21862951: MYSQLD_SAFE ERROR LOG TIMESTAMP DIFFERS WITH MYSQLD ERROR LOG
    
    mysqld 5.6 timestamped as per "date +'%Y-%m-%d %H:%M:%S'",
    its mysqld_safe        as per "date +'%y%m%d %H:%M:%S'".
    mysqld 5.7+ timestamps as per "date -u +%Y-%m-%dT%H:%M:%S.%06NZ",
    or optionally          as per "date +%Y-%m-%dT%H:%M:%S.%06N%:z".
    
    Support either format in mysqld_safe; default to UTC ISO8601,
    like mysqld (5.7+) does. Support --mysqld-safe-log-timestamps,
    an analog of mysqld's --log-timestamps that will be in line
    with the naming suggested in WL#8053.
    
    --mysqld-safe-log-timestamps=UTC|SYSTEM|LEGACY|HYPHEN

commit 6ea5ab0b32ed66473ff85e150c4f95358e6f1ca0
Merge: 292bf85 bb6430f
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Thu Nov 26 11:19:13 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit bb6430fe864191b8530208e0c319bb9918d86351
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Thu Nov 26 11:17:31 2015 +0530

    Bug#21276561:FAILURE TO GENERATE GTID LEADS TO INCONSISTENCY
    
    Fixing a post push test issue.
    
    POST PUSH TEST ISSUE:
    ====================
    
    binlog_gtid_exhausted.test has failed in weekly-trunk with
    following symptoms.
    
    -ERROR HY000: Binary logging not possible. Message: An error
    occurred during flush stage of the commit.
    'binlog_error_action' is set to 'ABORT_SERVER'. Hence
    aborting the server.
    +ERROR HY000: Binary logging not possible. Message: Hence
    aborting the server.
    
    Analysis:
    ========
    
    Existing code uses 'errmsg' char array as both source and
    destination within a 'sprintf' statement.
    
    As per the documentation, If copying takes place between
    objects that overlap as a result of a call to sprintf() or
    snprintf(), the results are undefined.
    
    This might be the reason for the above failure.
    
    Hence added a new destination buffer to hold the resulting
    error string.
    
    In addition to that added a new 'master.opt' file with
    '--skip-core-file'.

commit 292bf857eb89f69e9f74cdd012281258ad89fffb
Merge: fc05b1f 37c9489
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Wed Nov 25 23:45:12 2015 +0100

    Merge branch 'mysql-5.6' into mysql-5.7

commit 37c9489e50f04694b603dcb53e67861067b08bb7
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Tue Nov 24 15:13:27 2015 +0100

    Bug#22194831 INSTALL-SOURCE AND INSTALL-WIN-SOURCE CONTAIN OUTDATED INFORMATION
    
    Follow-up patch: remove Docs/INSTALL-BINARY, the information has been moved to INSTALL.

commit fc05b1f101098bc30de2f8cba133a9d750cc9e9b
Merge: d16b42d 7a58b6a
Author: Joao Gramacho <joao.gramacho@oracle.com>
Date:   Wed Nov 25 12:13:20 2015 +0000

    Merge branch 'mysql-5.6' into mysql-5.7

commit 7a58b6ac836c4c983a4fab60cc55618c43d70d65
Author: Joao Gramacho <joao.gramacho@oracle.com>
Date:   Wed Nov 25 10:16:39 2015 +0000

    BUG#22245619 SERVER ABORT AFTER SYNC STAGE OF THE COMMIT FAILS
    
    Problem:
    
    The binary log group commit sync is failing when committing a group of
    transactions into a non-transactional storage engine while other thread
    is rotating the binary log.
    
    Analysis:
    
    The binary log group commit procedure (ordered_commit) acquires LOCK_log
    during the #1 stage (flush). As it holds the LOCK_log, a binary log
    rotation will have to wait until this flush stage to finish before
    actually rotating the binary log.
    
    For the #2 stage (sync), the binary log group commit only holds the
    LOCK_log if sync_binlog=1. In this case, the rotation has to wait also
    for the sync stage to finish.
    
    When sync_binlog>1, the sync stage releases the LOCK_log (to let other
    groups to enter the flush stage), holding only the LOCK_sync. In this
    case, the rotation can acquire the LOCK_log in parallel with the sync
    stage.
    
    For commits into transactional storage engine, the binary log rotation
    checks a counter of "flushed but not yet committed" transactions,
    waiting until this counter to be zeroed before closing the current
    binary log file.  As the commit of the transactions happen in the #3
    stage of the binary log group commit, the sync of the binary log in
    stage #2 always succeed.
    
    For commits into non-transactional storage engine, the binary log
    rotation is checking the "flushed but not yet committed" transactions
    counter, but it is zero because it only counts transactions that
    contains XIDs. So, the rotation is allowed to take place in parallel
    with the #2 stage of the binary log group commit. When the sync is
    called at the same time that the rotation has closed the old binary log
    file but didn't open the new file yet, the sync is failing with the
    following error: 'Can't sync file 'UNOPENED' to disk (Errcode: 9 - Bad
    file descriptor)'.
    
    Fix:
    
    For non-transactional only workload, binary log group commit will keep
    the LOCK_log when entering #2 stage (sync) if the current group is
    supposed to be synced to the binary log file.

commit d16b42d279271639f959268b4c0f514a86a002c7
Author: Deepa Dixit <deepa.dixit@oracle.com>
Date:   Wed Nov 25 16:09:27 2015 +0530

    WL#8904 GIS : Create a MTR test for checking replication with GEOMETRY data
    
    A MTR test which checks replication with
    GEOMETRY data has been added.
    
    Reviewed-by : Pavan Naik <pavan.naik@oracle.com>
    RB : 10611

commit 58bc004bf72ad7d1ba112696d368a3e29f048b2c
Author: Benny Wang <benny.wang@oracle.com>
Date:   Mon Nov 23 03:45:42 2015 +0100

    Fixed bug#22095783: ALTER TABLE ADD COLUMN FAILS WITH OUT OF RANGE VALUE ERROR
    
    ALTER TABLE which added index on virtual generated column using INPLACE
    algorithm did not properly report warnings (errors in strict mode) about
    problems with virtual column values. However any subsequent ALTER TABLE on the
    same table using COPY algorithm was producing such warning or even failing in
    strict mode due to evaluating problematic value. Moreover, such failure left
    connection in a state which made further INPLACE ALTERs on the table fail due
    to the same reason.
    
    The latter problem was actually more generic. Any ALTER TABLE which was
    executed using COPY algorithm and failed during copying phase left connection
    in such a state that made further ALTER TABLEs which tried to evaluate
    problematic generated column value fail (or emit warning) even if INPLACE
    algorithm was used. This also affected further SELECTs on this connection as
    they have started to produce warnings in situations in which it normally
    doesn't happen.
    
    This patch solves the first part of the problem by setting
    THD::count_cuted_fields to CHECK_FIELD_WARN for the branch of ALTER TABLE
    which handles in-place case. This ensures that evaluation of virtual column
    values during in-place ALTER TABLE generates proper warnings/errors and should
    not have any negative side-effects as in-place ALTER TABLE implementation
    doesn't call any other code sensitive to THD::count_cuted_fields value.
    
    The second part of the problem is solved by ensuring that
    THD::count_cuted_fields is reset back to CHECK_FIELD_IGNORE on all paths
    leaving ALTER TABLE code.

commit add42af88364ba297fe4df35ce7465bfa6ae8f3f
Author: Marc Alff <marc.alff@oracle.com>
Date:   Mon Nov 23 10:30:22 2015 +0100

    Bug#22130453 HANDLE_FATAL_SIGNAL (SIG=11) AT GET_FILENAME_HASH_PINS
    
    For some combination of consumers,
    the performance schema file instrumentation could fail while attempting
    to use a NULL pointer, while instrumenting temporary file io.
    
    The root cause is that, in pfs_end_file_close_wait_v1(),
    closing a temporary file always uses the thread instrumentation.
    
    This thread instrumentation, however, is only set conditionally,
    when the consumer "thread_instrumentation" is enabled.
    
    The fix is to always retreive the thread instrumentation pointer,
    when instrumenting file io operation, because it is needed
    to maintain the LF_HASH of instrumented files.

commit fc346eb178be701ea06ea09fbede0ed6222b3881
Author: Marc Alff <marc.alff@oracle.com>
Date:   Mon Nov 23 09:27:34 2015 +0100

    Bug#22118669 ASSERTION `PFS_FILE != __NULL' FAILED
    
    Before this fix, an assert failed in the server,
    in function pfs_end_temp_file_open_wait_and_bind_to_descriptor_v1().
    
    The root cause is that, in the performance schema file instrumentation,
    the code should not assume that instrumenting a temporary file open
    operation always results in an instrumented file.
    
    In particular, when the server runs out of instrumented file,
    a NULL PFS_file pointer is a valid, normal path.
    
    The fix is to relax the assert.

commit 4bc2a5193e849fdbb75ba369eb4ca953201d76e8
Author: Dmitry Shulga <dmitry.shulga@oracle.com>
Date:   Tue Nov 24 14:26:10 2015 +0600

    Follow-up for the BUG#21463167 - GTIDS: LOCK_OPEN DEADLOCK WITH REVOKE INCIDENT + SHOW TABLE STATUS CONCURREN
    
    Disabled running of a bug's test in embedded mode.
    Also name of a test file was changed to conform with requirement
    that for public test suite a name shouldn't contain the prefix bug#.

commit 6097f7cbf5ac4b4db62696a1e95a76230f884cd3
Merge: 3437951 4cde350
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Mon Nov 23 21:49:50 2015 +0530

    Bug #20201006 spamming show processlist prevents old
    connection threads from cleaning up.
    
    Analysis
    =========
    Issue here is, delay in connection cleanup for which global
    connection counter is already decremented, makes room for
    new connections. Hence more than expected connections are
    observed in the server.
    
    Connections running statement "SHOW PROCESSLIST" or "SELECT
    on INFORMATION_SCHEMA.PROCESSLIST" acquires mutex
    LOCK_thd_remove for reading information of all the connections
    in server. Connections in cleanup phase, acquires mutex to
    remove thread from global thread list. Many such concurrent
    connections increases contention on mutex LOCK_thd_remove.
    
    In connection cleanup phase, connection count is decreased
    first and then the thd is removed from global thd list. This
    order makes new connection (above max_connections) possible
    while existing connections removal is still pending because
    of mutex LOCK_thd_remove being held by show processlist.
    
    Fix:
    =====
    In connection clean phase, thd is removed from the global
    thd list first and then global connection count is
    decremented. Added code to wait for connection_count be
    be zero during shutdown to ensure connection threads are
    done with their task.
    
    Because of this change, tests which verifies PROCESSLIST and
    then status variable "threads_connected" might fail on slower
    machines. As part of this patch, changed test cases to wait
    until "threads_connected" is set to expected value instead
    of PROCESSLIST count.

commit 4cde35096e9b214e0b858d68bd7a4793dfb7506b
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Mon Nov 23 21:43:02 2015 +0530

    Bug #20201006 spamming show processlist prevents old
    connection threads from cleaning up.
    
    Analysis
    =========
    Issue here is, delay in connection cleanup for which global
    connection counter is already decremented, makes room for
    new connections. Hence more than expected connections are
    observed in the server.
    
    Connections running statement "SHOW PROCESSLIST" or "SELECT
    on INFORMATION_SCHEMA.PROCESSLIST" acquires mutex
    LOCK_thd_remove for reading information of all the connections
    in server. Connections in cleanup phase, acquires mutex to
    remove thread from global thread list. Many such concurrent
    connections increases contention on mutex LOCK_thd_remove.
    
    In connection cleanup phase, connection count is decreased
    first and then the thd is removed from global thd list. This
    order makes new connection (above max_connections) possible
    while existing connections removal is still pending because
    of mutex LOCK_thd_remove being held by show processlist.
    
    Fix:
    =====
    In connection clean phase, thd is removed from the global
    thd list first and then global connection count is
    decremented. Added code to wait for connection_count be
    be zero during shutdown to ensure connection threads are
    done with their task.

commit 34379511fb65679754a3fdf5ad759b94348c46ce
Author: Dmitry Shulga <dmitry.shulga@oracle.com>
Date:   Mon Nov 23 21:38:20 2015 +0600

    BUG#21463167 - GTIDS: LOCK_OPEN DEADLOCK WITH REVOKE INCIDENT + SHOW TABLE STATUS CONCURRENTLY
    
    For mysql server started with GTID_MODE=ON concurrent running of the statements
    SHOW TABLE STATUS and REVOKE ALL PRIVILEGES could lead to deadlock in case
    there is a view in database and REVOKE ALL PRIVILEGES partially failed for
    some of requested users, that is some users are handled successfully and
    some of them are failed.
    
    The reason for deadlock is that SHOW TABLE STATUS acquires the lock LOCK_grant
    within mysql_make_view() while holding LOCK_open whereas REVOKE ALL PRIVILEGES
    acquires LOCK_open holding LOCK_grant. The sequence of acquiring LOCK_grant,
    LOCK_open while handling REVOKE ALL PRIVILEGES happens only for the case when
    some of users listed in the statement arguments are handled successfully and
    some of them are failed AND the server is started with GTID_MODE=ON.
    In this case mysql_revoke_all() calls MYSQL_BIN_LOG::write_incident() that
    finally call open_table() on behalf of Gtid_table_access_context::init().
    On the other hand, acquiring of locks in the order LOCK_open, LOCK_grant while
    handling the statement SHOW TABLE STATUS happens in case there is a view and
    mysql_make_view() is called from open_table().
    
    There are two approaches to resolve this issue. The first one is to release
    LOCK_grant before calling MYSQL_BIN_LOG::write_incident() while handling
    REVOKE ALL PRIVILEGES. This modification could led potentially to reordering
    in binlog of statement REVOKE ALL PRIVILEGES with other statements running
    at the same moment. So this approach is too risky. The second one is to
    release LOCK_open just right after a view definition was read from the data
    dictionary. The second approach forces us to make refactoring that splits
    mysql_make_view() into two functions: open_and_read_view() and
    parse_view_definition(), replaces all occurences of mysql_make_view() by these
    two functions and releases LOCK_open just right after open_and_read_view()
    returned.
    
    To have a test case for this bug the function check_table_access()
    was modified in order to return immediately in case the debug variable
    force_check_table_access_return_ok is set. This allows to execute
    SET DEBUG_SYNC='...' from the test case while holding LOCK_grant.

commit 93e21fb86976c202d4b803facc891c443c4dba59
Merge: 1c9d033 73c9b73
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Nov 23 09:34:02 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 73c9b7335eaa873cdc0ec195fc1e9297f09c745b
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Nov 23 09:32:50 2015 +0530

    Bug#21486161: FLUSH_CACHE_TO_FILE CALLS _EXIT WHEN
    ABORT_SERVER.
    
    Added '--skip-core-file' option to
    binlog_error_action-master.opt file to avoid generation of
    core files.

commit 1c9d033a4650b51161e86d2cb6d6523fa9928f1a
Merge: fe109d6 ca169a7
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Sat Nov 21 11:15:14 2015 +0530

    Null Merge from branch 'mysql-5.6' into mysql-5.7

commit ca169a7e2e549dc17873004f7a9121b2aa5684df
Merge: 3d7342c 851d144
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Sat Nov 21 11:13:36 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 851d1440e9c4120556d091cadcd49c7fc5b15906
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Sat Nov 21 11:08:44 2015 +0530

    Bug #17047208	REPLICATION DIFFERENCE FOR MULTIPLE TRIGGERS
    
    Fixing pb2 valgrind failure
    Missed a 'if condition' check while moving the logic
    from one place to another place.

commit fe109d61d30e174b93cf3072cd11c6c69a9c2a9e
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Fri Nov 20 12:52:13 2015 +0100

    Bug#22224313 ADD -DWITH_BOOST=SYSTEM OPTION AND SPLIT SHIPPED BOOST FILES
    
    The server uses boost files for two different things:
    
     a) GIS subsystem using boost header files only
     b) mysqlpump building a private version a boost crono, thread and more
    
    A very valid request from the Linux distros is to be able to build against
    system installed boost which is maintained and where fixes
    are applied in a timely manner.
    
    So, on a build host with the correct version of boost installed
    (currently 1.59) this patch adds support for running cmake without
    any WITH_BOOST or BOOST_ROOT argument. For uniformity with other
    -DWITH_xxx arguments we have, -DWITH_BOOST=system is also supported.

commit d02eed42ce96d52c28a007105bd056003bbff315
Author: Christopher Powers <chris.powers@oracle.com>
Date:   Fri Nov 20 16:46:16 2015 +0100

    Bug#22225549 MYSQL_CHANGE_USER/MYSQL_RESET_CONNECTION+SET INNODB_*:LOGIN NOT POSSIBLE
    
    Update of plugin-defined session variable triggers resync with global
    variables and deadlocks on THD::LOCK_thd_sysvar in
    alloc_and_copy_thd_dynamic_variables().
    
    In alloc_and_copy_thd_dynamic_variables(), removed LOCK_thd_sysvar and
    extended the coverage of LOCK_global_system_variables

commit 53673a96ea733f324c51726e62cdefbc5ae5e50d
Author: Dag Wanvik <dag.wanvik@oracle.com>
Date:   Fri Nov 20 15:28:32 2015 +0100

    Bug#21922202 QUANTIFIED COMPARISON READS UNINITIALIZED DATA
    
    Follow-up[1] commit: adding new test files.
    
    [1] to commit 2744656ea76df58632acbef76b0aba463a900362

commit a0bc15e194ce014d9ee98c1534ca004760901ed2
Author: Knut Anders Hatlen <knut.hatlen@oracle.com>
Date:   Fri Oct 23 13:00:21 2015 +0200

    Bug#22077611: UPDATE .. WHERE JSON_EXTRACT(..) = '..' NOT USING VIRTUAL COL INDEX
    
    Expressions that match an indexed generated column may be replaced
    with the generated column in JOIN::optimize(), which enables use of
    the associated index. Single-table update and delete statements don't
    have a JOIN data structure, so this optimization is not performed for
    such statements.
    
    This patch changes JOIN::substitute_gc() into a free function, which
    is used from single-table update and delete statements as well as from
    JOIN::optimize(). With this change, single-table update and delete
    statements can use indexes on generated columns for filtering and
    ordering, even if the statements use the generated column expression
    instead of an explicit reference to the column.

commit ecd12bf6fd773cf7b39437153ee03323580c9d1c
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Fri Nov 20 13:37:58 2015 +0100

    Backport from mysql-trunk to mysql-5.7 of:
    
    commit dbc8bd1a451b0a3957b5657d97881d1dab49a62c
    Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
    Date:   Thu Nov 19 14:03:28 2015 +0100
    
        Bug#21650559: MYSQLPUMP MAKES CORRUPTED DUMP WHEN TABLE HAS GENERATED COLUMN
    
        Post-push fix: Add mysql_object_reader.cc to the list of
        files where it is necessary to ignore Boost compilation warnings.

commit ff53504b5c0821c363408061f8e1dbec729a857c
Merge: 5bb255b 3d7342c
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Nov 20 15:32:48 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 3d7342c6705bd4bf7f4e798e728ec4bfecbd42a8
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Nov 20 15:31:04 2015 +0530

    Bug #19183565 CREATE DYNAMIC INNODB_TMPDIR VARIABLE TO CONTROL
    		WHERE INNODB WRITES TEMP FILES
    
    	- Post push fix to address formatting issue.

commit 5bb255b0fea95fa9194ce05dac3b708feb23f048
Merge: 1d244e7 6cd9b75
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Nov 20 15:06:43 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 6cd9b7554921fbc125387108420ade658a82f99a
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Nov 20 15:05:12 2015 +0530

    Bug #19183565 CREATE DYNAMIC INNODB_TMPDIR VARIABLE TO CONTROL
    		WHERE INNODB WRITES TEMP FILES
    
    	- Post push fix to address pb2 failure.

commit 1d244e7dd2fa5ca578b25a7dcccef4834fcbf03f
Merge: 9e277f1 863c81e
Author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
Date:   Fri Nov 20 12:33:01 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 863c81e92ea021f28fffbae436928d059c6786fe
Merge: d6dbbfe 2590c93
Author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
Date:   Fri Nov 20 12:31:43 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 2590c93eb604ba07867d38718f21cb3f09f0c75d
Author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
Date:   Fri Nov 20 12:30:15 2015 +0530

    Bug#19941403: FATAL_SIGNAL(SIG 6) IN BUILD_EQUAL_ITEMS_FOR_COND | IN SQL/SQL_OPTIMIZER.CC:1657
    
    Problem:
    At the end of first execution select_lex->prep_where is pointing to
    a runtime created object (temporary table field). As a result
    server exits trying to access a invalid pointer during second
    execution.
    
    Analysis:
    While optimizing the join conditions for the query, after the
    permanent transformation, optimizer makes a copy of the new
    where conditions in select_lex->prep_where. "prep_where" is what
    is used as the "where condition" for the query at the start of execution.
    W.r.t the query in question, "where" condition is actually pointing
    to a field in the temporary table. As a result, for the  second
    execution the pointer is no more valid resulting in server exit.
    
    Fix:
    At the end of the first execution, select_lex->where will have the
    original item of the where condition.
    Make prep_where the new place where the original item of select->where
    has to be rolled back.
    Fixed in 5.7 with the wl#7082 - Move permanent transformations from
    JOIN::optimize to JOIN::prepare
    
    Patch for 5.5 includes the following backports from 5.6:
    
    Bugfix for Bug12603141 - This makes the first execute statement in the testcase
    pass in 5.5
    
    However it was noted later in in Bug16163596 that the above bugfix needed to
    be modified. Although Bug16163596 is reproducible only with changes done for
    Bug12582849, we have decided include the fix.
    
    Considering that Bug12582849 is related to Bug12603141, the fix is
    also included here. However this results in Bug16317817, Bug16317685,
    Bug16739050. So fix for the above three bugs is also part of this patch.

commit 9e277f1923bcffa773c3816154b43156fdea8d95
Merge: 302fe03 d6dbbfe
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Fri Nov 20 12:10:41 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit d6dbbfe615cb3dc2fcc951bf004a6d999d0bd121
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Fri Nov 20 12:09:52 2015 +0530

    BUG#21253415 MULTIPLE DROP TEMP TABLE STATEMENTS IN SF CAUSE REPLICATION
     FAILS USING 5.6 GTID
     Problem: When there are more than one drop temp table in stored function
              or trigger, replication is failing when GTIDs are enabled.
    
     Analysis: In ROW based replication format, even though CREATE TEMPORARY
               TABLE query is not replicated, DROP TEMPORARY TABLE queries
               are replicated to achieve proper clean up on Slave end (CREATE
               TEMPORARY TABLE query would have executed and replicated when
               the replication format is STATEMENT) by adding 'IF EXISTS'
               clause. When DROP TEMPORARY TABLE query is in a stored function
               along with some DML statements, the binlog equivalent query
               for that function execution will look like
               BEGIN
                 DROP TEMP TABLE ...
                 ROW EVENT FOR DML 1
                 ROW EVENT FOR DML 2
               END
               But when GTIDs are enabled, it is documented that CREATE/DROP
               TEMPORARY TABLE queries are not allowed in Multi Statement
               Transactions because half executed gtid transactions (rolled
               back of these transactions) can leave these temporary tables
               in a bad state.
               In the old code, one DROP TEMPORARY TABLE in a function is
               working fine because the 'DROP TEMP TABLE' is going into
               STMT_CACHE (which does not be wrapped with BEGIN/COMMIT).
               //STMT_CACHE
               GTID_EVENT
               DROP TEMP TABLE ...
               //TRANS_CACHE
               GTID_EVENT
               BEGIN
                 ROW EVENT FOR DML 1
                 ROW EVENT FOR DML 2
               END
    
               But if the function contains two 'DROP TEMP TABLE's, both
               of them are going into 'STMT_CACHE' (which does not be wrapped
               with BEGIN/COMMIT) and STMT_CACHE with one gtid_event cannot
               accommodate two separate DROP TEMP TABLE queries. And with above
               Multi Statement Transactions + GTID restriction, we cannot
               add 'BEGIN/COMMIT'.
    
    Fix:  Stored functions and Triggers are also considered as another form of
          Multi Statement Transactions across the server. To maintain gtid
          consistency and to avoid the problems that are mentioned in this bug
          scenario,  CREATE/DROP temp tables are disallowed from stored functions
          and triggers also just like how they were restricted in Multi Statement
          Transactions. Now function execution that has CREATE/DROP TEMP TABLES
          will throw ER_GTID_UNSAFE_CREATE_DROP_TEMPORARY_TABLE_IN_TRANSACTION.
          ("When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1, the statements CREATE
            TEMPORARY TABLE and DROP TEMPORARY TABLE can be executed in a
            non-transactional context only, and require that AUTOCOMMIT = 1. These
            statements are not allowed in Functions or Triggers also as they are also
            considered as Multi Statement transaction.)

commit 302fe0326ea3e2379086f405299030e28e2f1c34
Author: Aditya A <aditya.a@oracle.com>
Date:   Fri Nov 20 11:52:20 2015 +0530

    Bug#22140944 WL8149: ADD TEST FOR THE ROW0LOG.CC FIX THAT WAS UNRELATED TO
    	             Bug21894654
    
    In function row_log_table_low() while writing the record into file
    we wrongly allocated the size of new virtual tuple for writing the
    old virtual tuple. This was fixed by the Bug 21894654. Adding the
    test case for the fix.

commit 84af8a77133d5bdbae0ce898e5edfb02c8abc8ac
Author: Darshan M N <darshan.m.n@oracle.com>
Date:   Fri Nov 20 09:47:40 2015 +0530

    Bug#22096661 UNCLEAR NOTE 'INNODB: NOT STARTED' IN THE ERROR LOG
    
    Issue:
    ======
    In the error log during MySQL 5.7.9 startup, sometimes the message
    [Note] InnoDB: not started is displayed which leads to confusion as it does
    not say what is not started at the moment.
    
    Fix:
    ====
    The message [Note] InnoDB: not started is changed to make it more
    informative.
    
    Reviewed-by: Satya Bodapati <satya.bodapati@oracle.com>
    Reviewed-by: Marko Mäkelä <Marko.Makela@oracle.com>
    RB: 11061

commit 201e62b294255f736f20fbbb3b5fda792ae74f01
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Fri Nov 20 10:33:04 2015 +0800

    Bug#22202788 GCOL:ASSERTION:0 IN ROW_SEL_GET_CLUST_REC_FOR_MYSQL AT
    ROW0SEL.CC
    
    For virtual column, and there's an index on it, we just log the prefix
    bytes of old value, this cause we can't find the cluster rec by these
    prefix bytes. So, for this case, we need to log whole value of it in
    updating.
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
    RB: 11053

commit 2744656ea76df58632acbef76b0aba463a900362
Author: Dag Wanvik <dag.wanvik@oracle.com>
Date:   Thu Nov 19 22:18:20 2015 +0100

    Bug#21922202 QUANTIFIED COMPARISON READS UNINITIALIZED DATA
    
    1. Single column case.
    
    The first subquery in the repro is always empty due to the "WHERE 0"
    clause and is a Item_singlerow_subselect (which is materialized due to
    single column and an AND condition) and will detect the emptiness in
    Item_in_optimizer::val_int ca. line 2309:
    
      cache->store(args[0]);
      cache->cache_value();     <--- leads to call of Item_subselect::exec
    
    However, later[1], we call into Item_in_subselect::exec and we modify
    the plan a bit:
    
       if (need_expr_cache && !left_expr_cache &&
            exec_method == EXEC_MATERIALIZATION &&
            init_left_expr_cache())
          DBUG_RETURN(TRUE);
    
    [1]  called from Item_in_optimizer::val_int's lines:
    
         /* The subquery has to be evaluated */
         (void) item_subs->val_bool_result(); <--------
    
    the interesting part being the call to init_left_expr_cache(). Now, this
    method sets up a cache for the (left) subquery for the IN (SOME) query
    by going directly at the field selected in the left subquery:
    
       Cached_item *cur_item_cache= new_Cached_item(unit->thd,
                                                    left_expr->element_index(i),
                                                    use_result_field);
    
    Just a little further down, we call (ca line 700 in item_subselect.cc)
    
       test_if_item_cache_changed
    
    which calls down the Cached_item_int all the way to the Item_field to
    get a value, but *does not go through the Item_singlerow_subselect*, so
    it misses the fact that we know the value is NULL due to the false WHERE
    condition.  Also, there has been no data read for the subquery (empty),
    so the field buffer has not been initialized and we see the read of
    uninitialized data.
    
    The fix checks if we saw the empty single row result set when first
    calling value->cache() in Item_in_optimizer::val_int at the top level,
    so that we omit setting up the (broken) left subquery cache in
    Item_in_subselect::exec.
    
    This fixes the problem, because this forces the logic to go through
    Item_singlerow_subselect which knows the set is empty. We will
    materialize the table with an empty set once; getting subsequent rows
    through Item_in_optimizer::val_int will see that all left columns are
    null, ca line 2368:
    
        if (all_left_cols_null && result_for_null_param != UNKNOWN &&
            !item_subs->dependent_before_in2exists())
        {
          /*
             This subquery was originally not correlated. The IN->EXISTS
             transformation may have made it correlated, but only to the
             left expression. All values in the left expression are NULL,
             and we have already evaluated the subquery for all NULL values:
             return the same result we did last time without evaluating the
             subquery.
          */
          null_value= result_for_null_param;
        }
    
    and this time result_for_null_param is no longer UNKNOWN, so we do an
    early return instead of evaluating the (left) subquery again.
    
    2. Multiple column case
    
    The multiple column case has another code path since it doesn't
    materialize, but uses the IN -> EXISTS transformation instead. As we
    shall see, this error also pertains to "missing" the information that
    the left operand of the IN is a subquery.
    
    [ Update: While work was happening on this patch, another patch went int
      that made the change described within the square brackets here
      redundant.
    
      e9f7689b179b0f6d773361240f10a5ca33fe9339
      Bug#22131961 CANNOT GET GEOMETRY OBJECT FROM DATA YOU SEND TO THE GEOMETRY FIELD
    
      In appendix I below I explain why this change made the change
      described here redundant.
    
      This code had another bug causing an attempt to evaluate the left
      subquery's columns at optimize time [cf. the val_int call in
      make_join_select attempted because the make_cond_for_table method
      mistakenly returned non-NULL due to wrong const-ness, see below], with
      an un-opened table, causing reading of uninitialized data.
    
      The root cause is that the marking of the condition with
      "depended_from" failed (for the multiple column case; whereas for a
      forced IN -> EXISTS transformation instead of materialization in the
      single column case, there was no issue) in
      Item_in_subselect::row_value_in_to_exists_transformer because it used
      the expressions directly to determine const-ness instead of (also)
      consulting the top level, i.e. the subquery. This is fixed by the new
      method is_really_constant. ]
    
    But there was another issue at execution time for the multiple column
    case: The row cache example holds the subquery, and the evaluation of it
    during Item_cache_row::cache_value's call to bring_value(), will find
    that the subquery contains no rows due to the impossible WHERE and short
    circuit evaluation.
    
    In the loop over columns in Item_cache_row::cache_value, we should not
    try to cache based on it qua example, since there will have been no rows
    read, so the bottom Item_field::val_xxx will read uninitialized
    data. Instead, we force the cache value to a null_value using the new
    method Item_cache::store_null.
    
    Regression tests have been added.
    
    Appendix I. Why the fix to Bug#22131961 made the introduction of
    is_really_constant() redundant.
    
    This patch, among other changes also contains this change (for
    Item_cache::Setup):
    
    // --------------------------------- sql/item.h --------------------
    // index 10d43fc..916718f 100644
    // @@ -5110,6 +5110,10 @@ public:
           if (((Item_field *)item)->table_ref)
             used_table_map= ((Item_field *)item)->table_ref->map();
         }
    +    else
    +    {
    +      used_table_map= item->used_tables();
    +    }
         return 0;
       };
       enum Type type() const { return CACHE_ITEM; }
    
    Originally, the test was (before we introduced is_really_constant):
    
      expr->element_index(i)->const_item()
    
    and in this case, the const_item() used looks like this:
    
      /*
        Returns true if this is constant (during query execution, i.e. its
        value will not change until next fix_fields) and its value is known.
        When the default implementation of used_tables() is effective, this
        function will always return true (because used_tables() is empty).
      */
      virtual bool const_item() const
      {
        if (used_tables() == 0)
          return can_be_evaluated_now();
        return false;
      }
    
    It was used_tables() that gave 0, i.e. the result was evaluated as
    can_be_evaluated_now() which gave true. After the change, used_tables is
    not 0, and we return false, which is correct for "a AND 1", cf the query
    
      SELECT (SELECT a AND 1, a AND 1 FROM t1 WHERE 0) IN (SELECT 1,1 FROM t1)
          FROM t1;
    
    It seems correct that used_tables should return something since a
    references t1.

commit 0a8b2e0d723ff5749574a02dd104b188260a9961
Merge: edbd1a7 dd2abff
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Nov 20 05:42:24 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit dd2abff64a37627add89dd66269139bc416c58b7
Merge: c2e32ca 88f397d
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Nov 20 05:41:32 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 88f397d1715c8b7e8224916060fb43704e233349
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Nov 20 05:40:39 2015 +0530

    Bug #22214867: MYSQL 5.5: MAIN.SUBSELECT AND OTHERS FAIL
                   WITH NEW VALGRIND
    
    Issue:
    ------
    Function signature in valgrind.supp requires a change with
    valgrind 3.11. Static function is replaced with wild card.

commit edbd1a7b972d06e3c23c4b4dbd41c35843b3dddf
Author: Dag Wanvik <dag.wanvik@oracle.com>
Date:   Thu Nov 19 17:33:20 2015 +0100

    Bug#22090717 WRONG RESULT FOR SELECT NULL IN (<SUBQUERY>)
    
    * Solution
    
    Make sure `make_cond_for_table' called from `make_join_select' doesn't
    identify the problem case as a constant condition, by making it
    "outer" relative to the subquery if the left side is nullable, see the
    new method `Item_in_subselect::mark_as_outer'. In Item_cache_row, we
    now initialize null_value based on the example instead of setting it
    to false.
    
    This makes the evaluation in `JOIN::exec' evaluate the condition
    without short circuiting due to a presumed empty result set. This
    ensures that `Item_in_subselect::value' is being set, so a NULL result
    is produced, see below in analysis section.
    
    Some execution plans change slightly, but should not have any
    significant performance impact since it only impacts the case of
    
                SELECT (constant) in (SELECT constant)
    
    If any of the above two constants are not constant,
    `make_cond_for_table' wouldn't produce a constant anyway.
    
    New tests were added to subquery.inc.
    The patch also solves 19822406, cf. the modified tests and results.
    
    * Analysis of the problem
    
    Query: SELECT NULL IN (SELECT 1 FROM t1);
    
    This is a regression introduced in commit c5accd92e6fef WL#6369: EXPLAIN for
    other thread.
    
    The reason is as follows:
    
    Optimization now happens *before* [1] Item_in_optimizer:val_int can
    impact the result [by turning off and on condition guards], cf this
    section
    
          /*
            Turn off the predicates that are based on column compares for
            which the left part is currently NULL
          */
          for (uint i= 0; i < ncols; i++)
          {
            if (cache->element_index(i)->null_value)
              item_subs->set_cond_guard_var(i, FALSE);  <--- impacts optimization
            :
          }
    
          :
          else
          {
            /* The subquery has to be evaluated */
            (void) item_subs->val_bool_result();    <----- optimized here before
    
    Since we have a NULL, the condition should not be triggered, cf. explanation
    for OUTER_FIELD_IS_NOT_NULL:
    
        /**
           In IN->EXISTS subquery transformation, new predicates are
           added: WHERE inner_field=outer_field OR inner_field IS NULL, as
           well as HAVING inner_field IS NOT NULL, are disabled *IF
           OUTER_FIELD IS A NULL VALUE* (emphasized by me)
        */
    
    The fallout is that the call to Item_func_trig_cond::val_int from
    make_join_select:
    
           longlong val_int() { return *trig_var ? args[0]->val_int() : 1; }
    
    sees *trig_var as true, returns 0, which makes make_join_select believe it is
    constant:
    
      if (const_cond != NULL)
      {
        const bool const_cond_result= const_cond->val_int() != 0;
        :
        if (!const_cond_result)
          DBUG_RETURN(true);
    
    The next piece of the puzzle is that if make_join_select returns 1, as we saw
    above, JOIN::optimize does:
    
      zero_result_cause=
          "Impossible WHERE noticed after reading const tables";
    
    This in turn leads to wrong result at execution time.
    
    At execution time this an early return from JOIN::exec, so the calling
    Item_in_subselect::val_bool doesn't set null_value to true (in part) because
    value didn't get set:
    
      bool Item_in_subselect::val_bool()
      {
        DBUG_ASSERT(fixed == 1);
        if (exec())
        {
          reset();
          return 0;
        }
        if (was_null && !value)   <------| value false, so null_value == FALSE
          null_value= TRUE;              | but was_null is false anyway, so
        return value;                    | responsibility falls to caller...
      }
    
    The setting of null_value happened at the caller site here in
    Item_in_optimizer::val_int :
    
      /* The subquery has to be evaluated */
      (void) item_subs->val_bool_result();
      if (!item_subs->value)      <------ this used to be true, so we always set
                                          null_value                    /
        null_value= item_subs->null_value;                             /
      else                                                            /
        null_value= TRUE;         <----------------------------------/
    
    but due to the early cut-off in execution, item_subs->value isn't true and we
    enter branch one, rather than two and get 0 rather than NULL.
    
    [1] The call to make_join_select now happes from this stack scenario:
    
    1 make_join_select  .../sql_optimizer.cc:7578
    2 JOIN::optimize  .../sql_optimizer.cc:509
    3 mysql_prepare_and_optimize_select  .../sql_select.cc:1106
    4 mysql_union_prepare_and_optimize  .../sql_union.cc:125
    5 mysql_optimize_prepared_inner_units  .../sql_union.cc:57
    6 mysql_select  .../sql_select.cc:1166
    7 handle_select  .../sql_select.cc:114
    8 execute_sqlcom_select  .../sql_parse.cc:4885
    
    (The method mysql_optimize_prepared_inner_units is new with the regression
    commit.)
    
    instead of earlier, as part of the Item_in_subselect::exec:
    
    1 make_join_select  .../sql_optimizer.cc:7568
    2 JOIN::optimize  .../sql_optimizer.cc:514
    3 subselect_single_select_engine::exec  .../item_subselect.cc:2724
    4 Item_subselect::exec  .../item_subselect.cc:641
    5 Item_in_subselect::exec  .../item_subselect.cc:766
    6 Item_in_subselect::val_bool  .../item_subselect.cc:1399
    7 Item::val_bool_result  .../item.h:1199
    8 Item_in_optimizer::val_int  .../item_cmpfunc.cc:2084
    9 Item::send  .../item.cc:6811
    10 Protocol::send_result_set_row  .../protocol.cc:847
    11 select_send::send_data  .../sql_class.cc:2479
    12 JOIN::exec  .../sql_executor.cc:148
    13 mysql_execute_select  .../sql_select.cc:1104
    14 mysql_select  .../sql_select.cc:1225
    15 handle_select  .../sql_select.cc:111
    16 execute_sqlcom_select  .../sql_parse.cc:4843

commit 39437af5bede09cfadca19cfc6b9b5e8456bafda
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 20:30:40 2015 +0100

    Bug#21964465 ST_INTERSECTION(POLYGON, POLYGON) RETURNS INCORRECT RESULT
    
    Add test case.

commit abea4a2b28079d48412b060c3234f3dd17e18076
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 20:26:30 2015 +0100

    Bug#21964079 ST_UNION(POLYGON, POLYGON) RETURNS INCORRECT RESULT
    
    Add one more test case.

commit d6ef715247da1e77dd5e407d3d87bd64cf116a65
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 20:19:48 2015 +0100

    Bug#21964049 ST_UNION() RETURNS ERROR WITH VALID GEOMETRY INPUT
    
    Add test cases.

commit 97389cc6bca174cacbd0b2e291ab8890dbf8e714
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 20:09:58 2015 +0100

    Bug#21964079 ST_UNION(POLYGON, POLYGON) RETURNS INCORRECT RESULT
    
    Add test cases.

commit 2257b1242aa97de72482bc2bb3119670bc00524e
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 20:05:45 2015 +0100

    Bug#21965285 ST_DIFFERENCE(POLYGON, [MULTI]POLYGON) RETURNS INCORRECT RESULT
    
    Add test cases. One is commented out because it is caused by a different bug which still needs to be fixed.

commit b1eb333d3b06496a23a1507d175e043385ef5f64
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 19:15:34 2015 +0100

    Bug#21783889 ASSERT GEOMETRY::EQUALS(CURRENT_ROBUST_RING.FRONT(),CURRENT_ROBUST_RING.BACK())
    
    Add test cases.

commit 1c0775bbd2245d797ebda22fc1621955b33e4c25
Author: Adam Wulkiewicz <adam.wulkiewicz@oracle.com>
Date:   Wed Nov 18 18:59:28 2015 +0100

    Merge Boost.Geometry code in order to fix several bugfixes.
    
    The state of Boost.Geometry: 4270ccce20b207f303691e23b62171e08be1fe91

commit ec9882818d033b6864f80e75a00a4d887df037c1
Merge: 07f1710 c2e32ca
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Thu Nov 19 16:43:36 2015 +0100

    Merge branch 'mysql-5.6' into mysql-5.7

commit c2e32cab82817cc3367235915e6207e9d5c773f8
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Thu Nov 19 16:32:43 2015 +0100

    Revert "Bug #19688135 ASYMMETRIC_ENCRYPT: UNINITIALIZED VALUE WHEN CHECKING FOR "PRIVATE KEY""
    
    This reverts commit 6f92f1c1e57a0ec41a6a12631eef23deecbba843.
    This reverts commit 7f9c073150e49e4626637bdbf9d540dd073403db.

commit 07f1710b4df400e70e1756b99aaa0035d219e126
Merge: 3bc0510 6f92f1c
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 19 19:28:56 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 6f92f1c1e57a0ec41a6a12631eef23deecbba843
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 19 19:28:05 2015 +0530

    Bug #19688135 ASYMMETRIC_ENCRYPT: UNINITIALIZED VALUE WHEN CHECKING FOR "PRIVATE KEY"
    
    Post push changes.
    Missed the closing braces.

commit 3bc05105ff47dc46baca8d8dffca9544b1666038
Merge: 6fe623b f655286
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 19 16:54:25 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit f65528633f4178b82f70c212714f78a2e9302a92
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 19 16:53:20 2015 +0530

    Bug #17618162 SSL CONNECTION NOT CONSIDERING THE VALUE SPECIFIED BY MYSQL_OPT_READ_TIMEOUT
    
    Description: SSL connection not considering the value
    specified by MYSQL_OPT_READ_TIMEOUT. Connect the client
    to server with MYSQL_OPT_READ_TIMEOUT lesser
    (i.e like 5 seconds) then the mysql_query() execution
    time(i.e in mysql_query() have query as "SELECT SLEEP(10)").
    For the above scenario we you get "Lost connection to MySQL
    server during query" error. And this is happening in non-ssl
    case. But in SSL connection case we are getting the query
    execution is successful.
    
    Analysis: When we set the MYSQL_OPT_READ_TIMEOUT as '5'
    under SSL connection, we call my_net_set_read_timeout()
    in mysql_real_connect(i.e CLI_MYSQL_REAL_CONNECT) and
    converts the vio->read_timeout to milliseconds and further
    we call run_plugin_auth() and further so on to ssl_do(),
    there we will make new vio and copy the timeout values to
    it. But here we have the timeouts already in milliseconds.
    And we are passing those milliseconds(as seconds) to
    vio_timeout(). Thus further those will be converted to
    incorrect milliseconds which leads to having 15000000
    milliseconds instead of 15000 milliseconds in case of SSL
    connections. Hence the read_timeout for the query is more
    and we are getting the results successfully.
    
    Fix: Since the updated value of vio->read_timeout and
    vio->write_timeout value always be in milliseconds, we
    are converting the milliseconds value of vio->read_timeout
    in vio_reset to seconds and calling vio_timeout().

commit 6fe623be1ae48af631a2d6fe740d374461f8c9a2
Author: Aditya A <aditya.a@oracle.com>
Date:   Thu Nov 19 16:42:11 2015 +0530

    There was typo in renaming the test.
    virtaul_debug.test  renamed virtual_debug.test

commit dcb329a79df3da06c234f65224716785641836d4
Merge: 31abe81 7f9c073
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 19 16:31:53 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 7f9c073150e49e4626637bdbf9d540dd073403db
Author: V S Murthy Sidagam <venkata.sidagam@oracle.com>
Date:   Thu Nov 19 16:31:16 2015 +0530

    Bug #19688135 ASYMMETRIC_ENCRYPT: UNINITIALIZED VALUE WHEN CHECKING FOR "PRIVATE KEY"
    
    Description:
    Valgrind warning "Conditional jump or move depends on uninitialised value(s)" noticed when
    a encrypt function is executed along with concat() function having a null string(i.e concat('',a))
    
    Analysis:
    In Item_func_concat::val_str() when we have "res2->length() == 0" we just "continue".
    And 'Ptr' string is not having the null terminated character. Hence valgrid is reporting the
    Warning(like conditional jump .... ) when the 'Ptr' string is used in function asymmetric_encrypt()
    through strstr() api. Where as in case of res2->length() > 0 we call res->append(*res2) and
    we append '0' to the 'Ptr' string. So, valgrind is happy that the string is properly null terminated.
    
    Also we also noticed that get_algo() and get_digest_mode() has similar issues.
    
    Fix:
    used my_memmem() which has size of the string arguments, instead of strstr().
    And to fix get_algo(), get_digest_mode() issues we null terminated the input string because my_memmem will work only for case sensitive strings.

commit 31abe813d796834f3153837d8d58dc173fdc24b0
Merge: 2553972 55ee9a8
Author: Sergey Glukhov <sergey.glukhov@oracle.com>
Date:   Thu Nov 19 13:40:09 2015 +0300

    Merge branch 'mysql-5.6' into mysql-5.7

commit 55ee9a89bb842fa0278b093780a425e605c52e3d
Author: Sergey Glukhov <sergey.glukhov@oracle.com>
Date:   Thu Nov 19 13:37:31 2015 +0300

    Bug#22173419 VALGRIND FAILURE IN MAIN.GROUP_MIN_MAX
    
    Query below produces valgrind warning:
    
    select a1,a2,b,min(c) from t2 where
    ((a1 > 'a') or (a1 < '9')) and (a2 >= 'b') and (b = 'a') and (c < 'h112')
    group by a1,a2,b;
    
    Problematic expession is (c < 'h112').
    SEL_ARG::min_range is is_null_string which has length=2, memcmp
    is executed with the length which is bigger than is_null_string.
    
    The fix: Do not perform comparison if one of the argument is NULL value.

commit 25539727f06e18ab35d2fdac993dc1018e9c8c7b
Author: Bharathy Satish <bharathy.x.satish@oracle.com>
Date:   Thu Nov 19 14:51:19 2015 +0530

    Bug #21650559 MYSQLPUMP MAKES CORRUPTED DUMP WHEN TABLE HAS GENERATED COLUMN
    
    Problem: mysqlpump does not generate correct INSERT sql statements in dump
    file for tables which have generated columns. This will lead to error during
    restore.
    
    Fix: For tables with generated columns mysqlpump first identifies all the
    generated columns before preparing the INSERT sql statement for any table.
    Then those generated columns are ignored in the column name list of INSERT
    sql so that these sql statements get executed correctly during restore.

commit 19b6dbebe8df2a1cfa6f04dbc3cc26fe05ff0eb6
Merge: 87d5467 c57bd76
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Thu Nov 19 15:23:51 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit c57bd769995cb109764bd6dce0466dad838c7403
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Thu Nov 19 15:19:23 2015 +0530

    Bug #19183565 CREATE DYNAMIC INNODB_TMPDIR VARIABLE TO CONTROL
    		WHERE INNODB WRITES TEMP FILES
    
    Problem:
    ========
    InnoDB creates temporary files for online ALTER statements in the tmpdir.
    In some cases, the tmpdir is too small, or for other reasons, not the best
    choice.
    
    Solution:
    =========
    Create a new dynamic session variable "innodb_tmpdir"
    that would determine where the temp files should create during alter
    operation.
    
    Behaviour of innodb_tmpdir :
    ===========================
    1) Default value is NULL.
    2) Valid inputs are any path other than mysql data directory path.
    3) Directory Permission and existence checked as a part of validation for
       innodb_tmpdir.
    4) If value is set to NULL, then temporary file created in the location of
       mysql server variable(--tmpdir).
    5) User should have file privilege to set the variable.
    6) If user provides a path which is symlink, then we resolve and store
       absolute path in innodb_tmpdir.
    7) Path should not exceed 512 bytes.
    8) Path should be a directory.
    
    Reviewed-by: Marko Mäkelä<marko.makela@oracle.com>
    Reviewed-by: Harin Vadodaria<harin.vadodaria@oracle.com>
    Reviewed-by: Jon Olav Hauglid<jon.hauglid@oracle.com>
    RB: 7628

commit 87d54671375ae83c1d61fc348ac2b3fc41e956b0
Author: Mithun C Y <mithun.c.y@oracle.com>
Date:   Thu Nov 19 15:17:06 2015 +0530

    Bug #18039215: RESULT MISMATCH AND TIMEOUTS IN TEST FOR JOIN BUFFER.
    
    Issue:
    ======
    1. Explain produces inconsistent number of rows.
    2. Test take more time and timeout might be because
       of allocation of 4GB mem for each join buffer
       when system is under stress to allocate the same.
    
    Solution:
    =========
    1. Analyze table has been added to stabilize explain
       results.
    2. A debug flag is introduced under which max
       allocation for join buffer will be restricted to
       100MB. This should be sufficient for data in test.

commit f1776bc790c0bd9bb7e53304b02c140ab6cd702a
Merge: df687cc 8da4ada
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Thu Nov 19 14:00:30 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 8da4ada6ff2dfab3fdf3909bf9bb02c7f0f48631
Merge: 1c6cb97 b2dcd42
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Thu Nov 19 13:59:55 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit b2dcd4269e203ab88c744f5b00a50f5ce17ff7ae
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Thu Nov 19 13:59:27 2015 +0530

    Bug#17047208        REPLICATION DIFFERENCE FOR MULTIPLE TRIGGERS
    
        Problem & Analysis: If DML invokes a trigger or a
        stored function that inserts into an AUTO_INCREMENT column,
        that DML has to be marked as 'unsafe' statement. If the
        tables are locked in the transaction prior to DML statement
        (using LOCK TABLES), then the same statement is not marked as
        'unsafe' statement. The logic of checking whether unsafeness
        is protected with if (!thd->locked_tables_mode). Hence if
        we lock the tables prior to DML statement, it is *not* entering
        into this if condition. Hence the statement is not marked
        as unsafe statement.
    
        Fix: Irrespective of locked_tables_mode value, the unsafeness
        check should be done. Now with this patch, the code is moved
        out to 'decide_logging_format()' function where all these checks
        are happening and also with out 'if(!thd->locked_tables_mode)'.
        Along with the specified test case in the bug scenario
        (BINLOG_STMT_UNSAFE_AUTOINC_COLUMNS), we also identified that
        other cases BINLOG_STMT_UNSAFE_AUTOINC_NOT_FIRST,
        BINLOG_STMT_UNSAFE_WRITE_AUTOINC_SELECT, BINLOG_STMT_UNSAFE_INSERT_TWO_KEYS
        are also protected with thd->locked_tables_mode which is not right. All
        of those checks also moved to 'decide_logging_format()' function.

commit df687cca2cfd8763c1f90ea7d0a068f88acab700
Author: Benny Wang <benny.wang@oracle.com>
Date:   Thu Nov 19 07:24:11 2015 +0100

    Fixed bug#22018979: RECORD NOT FOUND ON UPDATE, VIRTUAL
     COLUMN, ASSERTION 0
    
    'ANSI' mode can cause the inconsistence on generated expression. Take a look
    at the example on the bug report. In order to remove such an inconsistence,
    this patch block ANSI mode when record generated expression in .frm which
    is the same way as view definition.

commit c4ebbc3efafb071297f11266a955f74d14b410f6
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Thu Nov 19 11:30:15 2015 +0530

    WL# 8196: TLS1.2 support.
    
    Post push, test fixes.

commit 0e4c0e47e3baff6e2a3a5bdd4fcba93434521551
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Tue Nov 17 09:19:32 2015 +0100

    Bug#22190656: UNDEFINED BEHAVIOR SANITIZER REPORTS MISALIGNED
                  STORE IN COMP_ERR
    
    Disable undefined behavior sanitizer warning about misaligned
    store in in the x86 implementation of int4store() and similar
    functions in byte_order_generic_x86.h. x86 CPUs handle misaligned
    reads and writes just fine.
    
    Also add CMake warning that undefined behavior sanitizer
    support is currently experimental.

commit 2dc562e4ec880dc8f878ced0a7e35af8b39bac0d
Author: Satya Bodapati <satya.bodapati@oracle.com>
Date:   Tue Nov 17 20:57:00 2015 +0530

    Bug#22154730 - INNODB: TRX_PURGE() RETURNS PREMATURELY DURING SLOW SHUTDOWN
    
    Problem:
    --------
    InnoDB slow shutdown doesn't work because of background threads
    (fts_optimize_thread, dict stats thread) adding undo to purge after/while
    the purge thread is exiting.
    
    Fix:
    ----
    Exit the background threads like fts_optimize_thread, dict stats thread
    before intiating purge shutdown.
    
    Also added debug assert which will catch if any thread is trying to add
    undo to purge history list after the purge thread is finished.
    
    Reviewed-By: Marko Makela <marko.makela@oracle.com>
    RB: 11046

commit d4008ce185f504e1e811bd122661b70df0e8501e
Author: Lalit Choudhary <lalit.choudhary@oracle.com>
Date:   Wed Nov 18 12:08:05 2015 +0530

    Bug#22150046 BOGUS TEST SNIPPET IN MAIN.AUDIT_PLUGIN_2
    
        Issue: Test has unwanted error and remove file lines.
    
        Fix: Since the testcase execution does not fail, it means that change_user
             actually succeeds.In this case no need for ERROR code and remove_file
             for change_user cmd. Removed ERROR code and remove_file, And also echo
             few comments so that it will be a good reference in out file.

commit c9eb32780ffa4935356e4a43466953c453f09eca
Merge: 11afada 1c6cb97
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Nov 18 08:05:41 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 1c6cb9701276f984a48fd8f8b0852710e7140672
Merge: 094c51e 8e2a9f3
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Nov 18 08:04:51 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 8e2a9f33f1c61b5b4b9eead22e64fd1d2b4ecaa5
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Nov 18 08:04:04 2015 +0530

    Bug #22214852: MYSQL 5.5 AND 5.6: MAIN.KEY AND OTHER
                   FAILURE WITH VALGRIND FOR RELEASE BUILD
    
    Issue:
    ------
    Initialization of variable with UNINIT_VAR is flagged by
    valgrind 3.11.
    
    SOLUTION:
    ---------
    Initialize the variable to 0.
    
    This is a backport of Bug# 14580121.

commit 11afadad8a58c9ae2b82ba6cfea5e65e25a3bdc5
Author: Maria Couceiro <maria.couceiro@oracle.com>
Date:   Fri Oct 9 12:27:51 2015 +0100

    BUG#21472492 SET GTID_PURGED START A TRANSACTION FOR MYSQL 5.7
    
    Problem:
    The SET GTID_PURGED statement is presenting a different behaviour
    for MySQL 5.6 and 5.7 servers. In MySQL 5.7 it is starting a
    transaction which might lead to an error when executing other
    statements, such as a SET SQL_LOG_BIN, without a previous commit.
    This behaviour is not observed in 5.6 servers.
    
    Analysis:
    Setting GTID_PURGED is initiating a transaction because the flag
    SERVER_STATUS_IN_TRANS was unecessarily activated when saving the
    purged gtid set in the table.
    
    Fix:
    The thd->lex->autocommit flag is set to true when the variable
    GTID_PURGED is set, ensuring that the transaction started during
    this statement is committed when it finishes.

commit 26522b2c2a8587aec3d23659bf8a3b4064ee1084
Merge: ed8560d 094c51e
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Tue Nov 17 11:23:04 2015 +0100

    Merge branch 'mysql-5.6' into mysql-5.7

commit 094c51ec137d830625025b83e7ae89b580b7fc1b
Author: Erlend Dahl <erlend.dahl@oracle.com>
Date:   Thu Nov 12 21:47:15 2015 +0100

    Bug#22194831 INSTALL-SOURCE AND INSTALL-WIN-SOURCE CONTAIN OUTDATED INFORMATION
    
    Removed two files that contained duplicate information:
    INSTALL-WIN-SOURCE and BUILD-CMAKE.
    
    Renamed INSTALL-SOURCE to INSTALL.
    
    Updated the information with correct links for different versions.
    
    Approved-by: Jon Hauglid <jon.hauglid@oracle.com>
    Approved-by: Terje Rosten <terje.rosten@oracle.com>

commit ed8560d499923b1cb1031538ddc46e9ddd06f51b
Merge: 7e128e4 cd3a7d9
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Nov 17 14:51:22 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit cd3a7d92b7fd8cda5aeea554f0ca91ba1b31e41a
Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
Date:   Tue Nov 17 14:50:49 2015 +0530

    Bug#21229951 VARIABLES IN ALTER EVENT NOT REPLICATED PROPERLY
    Problem: SP local variables that are used in ALTER EVENT
    are not replicated properly.
    
    Analysis: CALL statements are not written into binary log. Instead
    each statement executed in SP is binlogged separately with the exception
    that we modify query string: we replace uses of SP local variables with
    NAME_CONST('spvar_name', <spvar-value>) calls. The code was written
    under the assumption that this replacement was not required for at all
    for all the queries in 'row' based format. But it can happen that DDLs
    (which are always binlogged in statement mode irrespective of binlog
    format) can also use SP local variables and they suffer due to the
    above assumption. 'ALTER EVENT' in this bug case is one such cases
    
    Fix: Any SP local variables used in a query should
    be replaced with NAME_CONST(...) except for the case when it is DML
    query and binlog format is 'ROW'.

commit 7e128e4208c8d056c35de55f54c7b776e6ab8eeb
Merge: c920440 3d99c59
Author: Mithun C Y <mithun.c.y@oracle.com>
Date:   Tue Nov 17 14:32:31 2015 +0530

    Null Merge 'mysql-5.6' into mysql-5.7

commit 3d99c59d258d0f8622f26fe76956b718d838e329
Author: Mithun C Y <mithun.c.y@oracle.com>
Date:   Tue Nov 17 14:30:51 2015 +0530

    Bug #19479836: TEST: UP_MULTI_DB_TABLE, SUITE: ENGINES/FUNCS FAILS ON 5.6 PB2.
    
    Issue:
    ======
    Change in join order in multi update statement can produce
    different results. main reason bug 16767011 and 18449085.
    But these fixes are only made on 5.7 back-porting same
    thing on 5.6 is little risky as considering to use temp
    table for first table in join order is done before conds
    are rearranged and pre-processed in make_join_select.
    Where as in 5.7+ such decision happens after
    make_join_select. This particular change from 5.7 to 5.6
    appears risky hence not back-porting the same.
    
    Solution:
    =========
    Re-writing the tests in 5.6 so it produces consistent
    plan (join orders). This solves sporadic failures.

commit c920440a96628ad20b0bb6dcd91c6011d6c4907f
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Fri Nov 13 18:55:18 2015 +0530

    Corrected changelog entries

commit e7926012fb990ce55665d4fed919bc73eea04dd4
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Tue Nov 17 13:53:25 2015 +0800

    Follow up patch for Bug#22027053 GIS: PURGE THREAD
    DIES IN RTREE CODE WITH SPATIAL DATA
    
    Fixed test cases failure of ASAN build.

commit 7402833287fef26e88a448ccde794f2fc684785a
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Tue Nov 17 08:40:39 2015 +0530

    Bug #22155786: GET NEGATIVE FOUND_ROWS() FOR UNION STMT
    
    Issue:
    ------
    The problem can occur under the following conditions:
    1) In a query with UNION, a particular query block
       statement with LIMIT ...OFFSET clause generates zero
       rows.
    2) Use of FOUND_ROWS() with SQL_CALC_FOUND_ROWS in the
       prior SELECT statement.
    
    In this case, FOUND_ROWS() might return a negative number
    of rows.
    
    SOLUTION:
    ---------
    While accumulating the total number of records to be
    returned by each SELECT in a UNION, check if the number of
    possible rows is less than the offset. In which case, the
    number of rows contributed by that SELECT should be taken
    as zero.

commit a5b2ed6b9a15e82026cb20bfa0abb210b3fa0e8b
Author: Daogang Qu <bill.qu@oracle.com>
Date:   Tue Nov 17 08:38:47 2015 +0800

    Bug#21691396  ER_GTID_NEXT_TYPE_UNDEFINED_GROUP ON BINLOGLESS SLAVE AFTER IO THREAD RECONNECT
    
    When slave applier thread is applying a partial transaction left in
    relay log, we set m_scope_info[Transaction_ctx::SESSION].m_ha_list
    on registering binlog engine. So we missed to set
    m_scope_info[Transaction_ctx::SESSION].m_ha_list if binlog is
    disabled on slave, then failed to clean the partial transaction
    context.
    
    To fix the problem, we clean the partial transaction context if the
    SERVER_STATUS_IN_TRANS flag of thd->server_status is set, since the
    flag must be set when beginning a new transaction regardless of
    binlog is enabled or not.

commit e1961b2fbd3c272738c944f2d09b03988de2de1a
Author: Erik Froseth <erik.froseth@oracle.com>
Date:   Thu Nov 12 13:54:40 2015 +0100

    Bug#22165582 ST_*FROMGEOHASH ROUNDS INCORRECTLY
    
    Problem
    =======
    The current implementation of Geohash decoding may yield the wrong
    result, due to the rounding algorithm being too aggressive.
    
    To my knowledge, there is no official Geohash specification. However, the
    wikipedia page on Geohash is written by the Geohash author, and is thus used
    as the specification. The page states the following:
    
      Final rounding should be done carefully in a way that
        min <= round(value) <= max
    
    This is violated by the current implementation (funfact: it is also violated by
    the reference implementation http://geohash.org). To illustrate this, a decoding
    example is given:
    
    Decode "xkcd" into a latitude value: We begin by translating "xkcd" into its
    binary representation:
    
    x: 11101
    k: 10010
    c: 01011
    d: 01100
    
    Full binary representation: 11101100100101101100. To decode the latitude value,
    we only use the odd bits (given that the first bit is bit number zero). Removing
    all the even bits, we end up with the binary value 1010011010. A bit value of
    '1' indicates that we should discard the lower half of the latitude range. A
    value of '0' indicates that we should discard the upper half of the range. This
    gives us the following decoding steps:
    
    Start  [-90.0       90.0        ]
    1      [  0.0       90.0        ]
    0      [  0.0       45.0        ]
    1      [ 22.5       45.0        ]
    0      [ 22.5       33.75       ]
    0      [ 22.5       28.125      ]
    1      [ 25.3125    28.125      ]
    1      [ 26.71875   28.125      ]
    0      [ 26.71875   27.421875   ]
    1      [ 27.0703125 27.421875   ]
    0      [ 27.0703125 27.24609375 ]
    
    From the specification, we see that the final value should be in the rage
    [27.0703125, 27.24609375]. However, the current implementation ends up with
    rounding the value to "27.0". Both "27.1" and "27.2" would be considered a
    correct result.
    
    Fix
    ===
    Add a while-loop to Item_func_latlongfromgeohash::round_latlongitude which
    ensures that the returned result is within the valid range. We also add some
    asserts to ensure that the returned result satisfy the Geohash rounding
    condition mentioned in the specification.
    
    Note that the result returned from MySQL geohash functions may not be the same
    results returned from http://geohash.org, due to the fact that the "reference
    implementation" have the same bug/flaw.
    
    Also, the bug report mentiones the following case:
    
      For some positions, you can get results that differ wildly:
    
      SELECT ST_GeoHash(ST_PointFromGeoHash('ebrb', 0), 4);
      +-----------------------------------------------+
      | ST_GeoHash(ST_PointFromGeoHash('ebrb', 0), 4) |
      +-----------------------------------------------+
      | s00j                                          |
      +-----------------------------------------------+
    
    With this bugfix, the result is now the following:
    
      SELECT ST_GeoHash(ST_PointFromGeoHash('ebrb', 0), 4);
      +-----------------------------------------------+
      | ST_GeoHash(ST_PointFromGeoHash('ebrb', 0), 4) |
      +-----------------------------------------------+
      | s020                                          |
      +-----------------------------------------------+
    
    This is however valid, as explained below:
    
      'ebrb' represents the bounding box with latitude [1.40625, 1.58203125]
      and longitude [-0.3515625, 0.0]. ST_PointFromGeoHash('ebrb') results in
      POINT(0.0 1.5) (which is valid).
    
      's020' represents the bounding box with latitude [1.40625, 1.58203125]
      and longitude [0.0, 0.3515625]. This is also a valid representation of
      POINT(0.0 1.5).

commit 4739983cef5716f6531fdd365ca62fb2e1409fdb
Merge: 28b5205 020f3f8
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Nov 16 15:45:48 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 020f3f8081c2ec7881f88b77760d65e0dd4c8b12
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Nov 16 15:43:00 2015 +0530

    Bug#21276561: FAILURE TO GENERATE GTID LEADS TO
    INCONSISTENCY
    
    Problem:
    =======
    If generating a GTID for a transaction fails, the
    transaction is not written to the binary log but still gets
    committed, which potentially leads to master/slave data
    inconsistency.
    
    Analysis:
    ========
    Running out of GTID numbers is a very rare scenario, but if
    that happens that will be a fatal error and we advise users
    to 'Restart the server with a new server_uuid'.
    
    GTID's are generated at the time of flushing binlog cache
    to actual binary log. In the existing code if generation
    of GTID fails, client will get an appropriate error message
    and the action specified as per the binlog_error_action
    will be taking place as this is a flush stage error. i.e
    if the user chose binlog_error_action to be 'IGNORE_ERROR',
    then binlog will be disabled and transactions will continue
    to get committed on master and this will lead to an
    inconsistent slave. If the user chose binlog_error_action
    to be 'ABORT_SERVER' then server will abort without
    commiting the transaction on master so it will be consistent
    with slave. This behavior is the most appropriate one. At
    present while displaying the error message in error log, it
    is displayed as 'sync' stage error but it should be a
    'flush' stage error.
    
    Fix:
    ===
    During flush stage if generation of GTID fails then we set
    thd->commit_error= THD::CE_FLUSH_ERROR, so that the error
    message is accurate.

commit 28b520527707b914c4c17c2d485d57c9efe00c27
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Fri Nov 13 12:47:28 2015 +0100

    Bug #22200984 ASSERTION IN FILESORT::MAKE_SORTORDER()
    
    Problem: make_sortorder() asserts in debug mode: we are not supposed to be
    sorting on outer references. If we switch off only_full_group_by then
    this schenario may happen.
    
    Solution: Relax the debug assert.

commit 6bc30f851fbd9d89a202248da4a150f531a99630
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Thu Nov 12 11:15:30 2015 +0100

    Bug#22147191	NO PACKAGE FOR UBUNTU 15.10
    
    * Adds wily (15.10) packaging

commit 0faf4ecf678115c3469e18184f1d611889d9890c
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Mon Nov 16 17:08:22 2015 +0800

    Bug#22027053 GIS: PURGE THREAD DIES IN RTREE CODE WITH SPATIAL DATA
    
    1:We didn't store the child page number field in R-tree search stage,
    then it can't find the correct internal node when purge want to get
    father node.
    2:We need to compare the child page number field, otherwise,
    page_cur_search_with_match can't find the correct rec.
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
    RB: 11024

commit 94442183ef0b14c580c80549fa17407dad89d14c
Merge: 92cc218 96e9007
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Mon Nov 16 11:57:48 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 96e90076b9a76b631b4e849af982cc7ab6d1ef10
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri Nov 13 12:22:30 2015 +0530

    Bug#21630907: MISSING DATA DETECTED WHEN MAX_BINLOG_SIZE
    SMALLER ON SLAVE FOR 3 NODE TOPOLOGY
    
    Bug#21053163: MIXED BASED REPLICATION LOOSES EVENTS WHEN
    RELAY_LOG_INFO_REPOSITORY=TABLE
    
    Problem:
    =======
    2 level replication M1 -> S1 ->S2 ( S1 is slave of M1; S2 is
    slave of S1) replicating a non-transactional storage engine
    table (e.g.MyISAM) when set relay_log_info_repository=TABLE;
    and binlog rotation occurs in the middle of statement that
    was translated to multiple rows, then you loose part of that
    events.
    
    When binlog rotation occurs, on S1 not all rows are written
    to it's binlog, therefore S2 seamlessly looses part of rows
    that were translated from one statement to several rows.
    
    Fix:
    ===
    The above mentioned bugs got fixed as part of BUG#16418100
    fix. Adding additional test cases to improve test coverage.

commit 92cc218108296e0824740f1ba79439bbf26f5b52
Author: Bharathy Satish <bharathy.x.satish@oracle.com>
Date:   Mon Nov 16 11:24:38 2015 +0530

    WL#8754 Deprecate COM_XXX commands which are redundant.
    
    COM commands are hard to extend as they need protocol change, with SQL
    statements there is no such restriction. There are few COM commands for
    which we have an equivalent SQL statements. Below is the list:
    
    COM_FIELD_LIST   - SHOW COLUMNS FROM statement
    COM_REFRESH      - FLUSH statement
    COM_PROCESS_INFO - SHOW PROCESSLIST statement
    COM_PROCESS_KILL - KILL CONNECTION/QUERY statement
    
    With this WL the above COM command will be deprecated and removed in future
    release.

commit bb4abbe7773926741e1096b3078b803fb03fcfce
Author: Bharathy Satish <bharathy.x.satish@oracle.com>
Date:   Mon Nov 16 09:50:28 2015 +0530

    Bug #21980284 MYSQLPUMP CAUSES INCONSISTENT BACKUP
    
    Problem: Due to parallelism the threads which start the dump process can view
    a different states of the database which can cause the dump to be inconsistent.
    
    Fix: To get a consistent backup we lock the server and flush all the tables.
    This is done with FLUSH TABLES WITH READ LOCK (FTWRL). This will ensure that
    any further connections will view the same state of all the databases which
    is ideal state to take backup.

commit 0a942734c82190f85cd78fa8cb88e6adfe2df0c8
Merge: 49362f0 82e2842
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Fri Nov 13 18:21:42 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 82e2842071513c6356f37a4d73577d33624a1f5e
Merge: 01a0558 22beefb
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Fri Nov 13 18:17:59 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 22beefba1ee608eee7106e078eb7470f515b6c26
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Fri Nov 13 18:04:31 2015 +0530

    Bug#20691429 ASSERTION `CHILD_L' FAILED IN STORAGE/MYISAMMRG/
    HA_MYISAMMRG.CC:631
    
    Analysis
    ========
    Any attempt to open a temporary MyISAM merge table consisting
    of a view in its list of tables (not the last table in the list)
    under LOCK TABLES causes the server to exit.
    
    Current implementation doesn't perform sanity checks during
    merge table creation. This allows merge table to be created
    with incompatible tables (table with non-myisam engine),
    views or even with table doesn't exist in the system.
    
    During view open, check to verify whether requested view
    is part of a merge table is missing under LOCK TABLES path
    in open_table(). This leads to opening of underlying table
    with parent_l having NULL value. Later when attaching child
    tables to parent, this hits an ASSERT as all child tables
    should have parent_l pointing to merge parent. If the operation
    does not happen under LOCK TABLES mode, open_table() checks
    for view's parent_l and returns error.
    
    Fix:
    ======
    Check added before opening view Under LOCK TABLES in open_table()
    to verify whether it is part of merge table. Error is returned
    if the view is part of a merge table.

commit 49362f02a877bd9035514ac06042c7ed727cefb8
Merge: df762b1 01a0558
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Fri Nov 13 17:55:31 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 01a0558be8c6f67a44ce2e2aa5777826912f49df
Merge: 0d33177 3b2afdc
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Fri Nov 13 17:53:46 2015 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 3b2afdc52ec0e04119e133cf0959ea1f802711ea
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Fri Nov 13 17:51:18 2015 +0530

    Bug#19817021 CRASH IN TABLE_LIST::PREPARE_SECURITY WHEN
    DOING BAD DDL IN PREPARED STATEMENT
    
    Analysis
    ========
    A repeat execution of the prepared statement 'ALTER TABLE v1
    CHECK PARTITION' where v1 is a view leads to server exit.
    
    ALTER TABLE ... CHECK PARTITION is not applicable for views
    and check for the same check is missing. This leads to
    further execution and creation of derived table for the view
    (Allocated under temp_table mem_root). Any reference to open
     view or related pointers from second execution leads to
    server exit as the same was freed at previous execution closure.
    
    Fix:
    ======
    Added check for view in mysql_admin_table() on PARTITION
    operation. This will prevent mysql_admin_table() from
    going ahead and creating temp table and related issues.
    Changed message on admin table view operation error to
    be more appropriate.

commit df762b19f94ab61765493945e7b95abc755919f8
Author: Marko Mäkelä <marko.makela@oracle.com>
Date:   Fri Nov 13 12:42:53 2015 +0200

    Bug#21549928 RACE CONDITION BETWEEN FIL_NAMES_WRITE()
    AND FIL_RENAME_TABLESPACE_IN_MEM()
    
    This is a regression from WL#7142.
    
    The tablespace file names (fil_node_t::name) were only protected by
    fil_system->mutex, but the MLOG_FILE_NAME reporting code is only holding
    log_sys->mutex. So, we have to protect the file names with both
    fil_system->mutex and log_sys->mutex. fil_system->mutex protection
    will be needed for fil_node_open_file() and possibly other users.
    
    fil_node_t::name: Document the mutex protection.
    
    fil_rename_tablespace_in_mem(): Remove.
    
    fil_rename_tablespace(): Protect fil_node_t::name by log_sys->mutex
    and fil_system->mutex. Check the validity of fil_space_t::name upfront.
    
    RB: 11014
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>

commit a46d093ea208544fca7aa8df2700440a62665979
Author: Horst Hunger <horst.hunger@oracle.com>
Date:   Fri Nov 13 11:03:00 2015 +0100

    created a hudson jon for 5.7 on solaris

commit 9ce421359697ecfa0e0c3a9a4845d883844209c7
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Fri Nov 13 16:06:07 2015 +0800

    BUG#22094601 CREATE TABLE WITH FULLTEXT AND CONSTRAINT FAILS
    WHEN FOREIGN_KEY_CHECKS IS 0
    
    we commit trx in fts_create_index_tables, in which reset
    trx_t::check_foreigns to true. The solution is using
    fts_create_index_tables_low instead.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 11023

commit 457d7bd5347ddd9ae42dbfb8e76c12e14074175c
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Fri Nov 13 08:42:31 2015 +0100

    Fixed syntax error in changelog file for debian7

commit 3b2b5a4ef204ee84701112d39ec4ecbb9e0add2e
Author: Aditya A <aditya.a@oracle.com>
Date:   Fri Nov 13 12:02:29 2015 +0530

    Bug #22025778       ADD TEST FOR MORE ONLINE LOG TEST, ALSO RENAME
                      INNODB_V_BASIC TO VIRTUAL_BASIC
    
    Refactoring the test cases ,moved the debug test cases in separate
    test case. Renamed innodb_v_basic.test to virtual_basic.test
    innodb_v_debug to  virtual_debug.test and innodb_v_purge to
    virtual_debug_purge.test

commit d3ad8bd6b72732593f8c16577e72c6c0f8930625
Merge: 6369238 0d33177
Author: Mayank Prasad <mayank.prasad@oracle.com>
Date:   Fri Nov 13 11:35:26 2015 +0530

    Merge branch 'mysql-5.6' into mysql-5.7

commit 0d3317794f4321cdf270229bd802ad0aa736e1c3
Author: Mayank Prasad <mayank.prasad@oracle.com>
Date:   Fri Nov 13 11:29:55 2015 +0530

    Bug #21765843 : ASSERTION `PFS->M_PROCESSLIST_ID != 0' FAILED IN TABLE_SESSION_CONNECT.CC:254
    
    Before this fix:
    	BACKGROUND threads are not supposed to have connection attributes
    	and therefore an ASSERT was in place to make sure this code point
    	is not reached from a BACKGROUND thread.
    	But when server is started with --thread-handling=no-threads, no
    	FOREGROUND thread is created for client connection and this code
    	point is reached when a query to table session_connect_attrs is
    	made, and an ASSERT was seen.
    
    After this fix:
    	Instead of an ASSERT, silently return from the function.

commit 6369238d7bb5cf88fec84438c0ee485199de03e5
Author: Yashwant Sahu <yashwant.sahu@oracle.com>
Date:   Fri Nov 13 08:49:49 2015 +0530

    WL#8196: TLS1.2 support.
    
    Post push test fix.

commit f4c62ad026d6dc22dfaa118f5d35cce3fa26edfc
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Thu Nov 12 13:27:35 2015 +0100

    Bug#22190632: ENABLING UNDEFINED BEHAVIOR SANITIZER FAILS LINKING
                  OF *_EMBEDDED EXECUTABLES
    
    Wrap usage of THD::slave_thread/THD::rli_slave in sql_base.cc
    in HAVE_REPLICATION #ifdefs so they are not compiled for embedded.
    This solves linking issue which appeared with -DWITH_UBSAN=1.

commit df7bda79e40a63d86f233fcddb4dfa2574e1338a
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Thu Nov 12 12:46:45 2015 +0100

    Add removal of upcoming decompress man pages, with comment

commit fb86049919f62d14378305d8755bc91a890e80ab
Author: Roy Lyseng <roy.lyseng@oracle.com>
Date:   Thu Nov 12 13:59:49 2015 +0100

    Bug#21875520 Problems with virtual column indexes
    
    The problem here is that Innodb detects a mismatch between the
    value of a column in an index versus the value in the "before" buffer
    when attempting an update operation.
    
    The problem occurs because virtual generated column values are
    calculated by fill_record() when doing an INSERT operation.
    However, if the table definition contains DEFAULT or ON UPDATE functions,
    these functions are evaluated after fill_record() is called.
    So, if a virtual column depends on a column updated by such function,
    a data inconsistency occurs.
    
    The minimum solution to this problem is to re-update the virtual columns
    if the table has a DEFAULT or ON UPDATE function and has virtual columns.
    This means that in a few cases, we update the virtual columns twice, but
    removing this inefficiency would require a larger refactoring, with
    higher risk.

commit beb2ed52a4aa111cc759533232d15f4da7fa7cda
Merge: 51e5112 5485716
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Thu Nov 12 11:35:19 2015 +0100

    Merge branch 'mysql-5.6' into mysql-5.7

commit 5485716b211ff55536a26c98ec654dd8ff6e2b55
Author: Lars Tangvald <lars.tangvald@oracle.com>
Date:   Thu Nov 12 11:15:30 2015 +0100

    Bug#22147191	NO PACKAGE FOR UBUNTU 15.10
    
    * Adds wily (15.10) packaging

commit 51e511255b803ca50edcde4be321666c5472acaf
Author: Mayank Prasad <mayank.prasad@oracle.com>
Date:   Thu Nov 12 15:37:19 2015 +0530

    Bug #21442376 	PERFSCHEMA.NO_THREADS : FAILS ON WINDOWS
    
    Issue:
     	The number of P_S-thread-instances were more than 20
            while it was restrited to 20 in test. Therfore few of
            the treads instrumentation were lost.
    
    Fix:
            The fix is to increase the limit (50 now).
    	Modified test case to verify if threads instrumentation
    	is lost.

commit 01be55cdbbc9e5f9d2cb59d1aafb87717d82a9c0
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Thu Nov 12 15:25:49 2015 +0530

    Followup fix for BUG#21950975 - MYSQL RPM INSTALLER(NEW STYLE) FAILS TO CREATE 'MYSQL' USER FOR EL5

commit a75cb32ba7a5a200fc0825d5f00d9aff6ca8bc34
Author: Marko Mäkelä <marko.makela@oracle.com>
Date:   Thu Nov 12 10:09:40 2015 +0200

    Follow-up to Bug#21896123 ADD/UPDATE IMPORTANT MEB SIDE CODE CHANGES
    IN INNODB SOURCE
    
    Revert some unintended and unapproved changes that were done
    in the commit a67a240b9ee821a5a2e1ae322a1e205aa80e5f8f.
    
    Original RB: 10865
    Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com>

commit 5dcb50b31216d4bd5f9e1e1dbdeeabc47641c033
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Thu Nov 12 08:48:19 2015 +0100

    WL#8196: TLS1.2 support
    
    Post-push fix: Update .result file.

commit 821f14d9c696bcdb34aaa16a1f6fd458a13c78bc
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Tue Nov 10 11:02:15 2015 +0100

    Bug#22174219 MEMORY LEAKS IN EMBEDDED SERVER
    
    There are several memory leaks, the most important one in embedded_get_error()
    
    Solution:
    In embedded_get_error(): call free_root before doing my_free(data);
    Remove call on udf_init() in embedded server.
    Move call to log_syslog_exit() from mysqld_exit() to clean_up()
    so that it is invoked by end_embedded_server()

commit ae8de3b7d5772310e92b5cabb5f72776f153c120
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Wed Nov 11 14:50:36 2015 +0800

    Followup fix for Bug#22139917 ASSERTION: DICT_TABLE_GET_NTH_COL(
    USER_TABLE, NTH_COL)->LEN < NEW_LEN
    
    Fixed release build failure.
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com> on IM.

commit 7fced68e71e15d6e63382f8844b4db2112223bf2
Author: Marko Mäkelä <marko.makela@oracle.com>
Date:   Wed Nov 11 07:59:26 2015 +0200

    Bug#22163880 INNODB: REMOVE RUNTIME CHECKS FOR 32-BIT FILE OFFSETS
    
    The InnoDB source code contains some checks for 32-bit off_t
    (file offset), trying to detect overflow when accessing files that
    exceed the 4 GiB barrier created by a 32-bit off_t.
    
    MySQL 5.7 officially supports only two 32-bit operating systems:
    Microsoft Windows, and various versions of Linux.
    
    cmake/os/Linux.cmake unconditionally defines the following:
    ADD_DEFINITIONS(-D_FILE_OFFSET_BITS=64)
    
    On Windows, we do not use off_t for file offset arithmetics,
    except in os_file_check_args(). On 32-bit Windows, after growing
    a file to 4GiB, fsp_reserve_free_extents() would fail, and
    we would return DB_OUT_OF_FILE_SPACE or ER_RECORD_FILE_FULL.
    So, the message in os_file_check_args() was unreachable.
    
    os_file_check_args(): Remove.
    
    Tablespace::get_sum_of_sizes(): Always return the sum of sizes,
    never ULINT_UNDEFINED.
    
    RB: 10975
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>

commit 2b7f645832bf342ebf5d89f76cd0ef9f1627ddcf
Author: Harin Vadodaria <harin.vadodaria@oracle.com>
Date:   Wed Nov 11 10:16:06 2015 +0530

    Bug#22185872 : INCOMPATIBILITY IN LIBMYSQLCLIENT VERSION BETWEEN 5.7.9 AND 5.7.10
    
    Description : 1. enum for new option --tsl_version was not
                     added at the end of the list.
                  2. Symbol version for existing libmysqlclient
                     symbols were changed from 20.0 to 20.1.
    
    Solution : 1. Moved MYSQL_OPT_TLS_VERSION to the end of
                  the list.
               2. For MySQL 5.7, corrected symbol version
                  of existing libmysqlclient symbols.
    
    Reviewed-By: Georgi Kodinov <georgi.kodinov@oracle.com>
    Reviewed-By: Norvald Ryeng <norvald.ryeng@oracle.com>

commit fc3690ec902016ad1a21dc198313f9c41ee2e34c
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Wed Nov 11 11:43:59 2015 +0800

    Bug#22139917 ASSERTION: DICT_TABLE_GET_NTH_COL(USER_TABLE,
    NTH_COL)->LEN < NEW_LEN
    
    We didn't handle alter table with enlarging the column length of virtual
    column.
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
    RB: 11010

commit 215d895c8e89e1abe38e2a515b7bdbedc2e75270
Author: Jimmy Yang <jimmy.yang@oracle.com>
Date:   Wed Nov 11 09:19:02 2015 +0800

    Bug#22141031 - GCOLS: PURGED THREAD DIES: TRIED TO PURGE NON-DELETE-MARKED
    RECORD IN INDEX
    
    Reviewed-by: Sunny Bains <sunny.bains@oracle.com>

commit eb62bb0a5c8300ecc596bb69dd52282c81324943
Author: Allen Lai <zheng.lai@oracle.com>
Date:   Tue Nov 10 19:27:12 2015 +0800

    Bug#22123674 VCOL:INNODB: FAILING ASSERTION:
    !UT_STRCMP(NAME, FIELD->FIELD_NAME)
    Bug#22111464 VCOL:INNODB: FAILING ASSERTION: I < TABLE->N_DEF
    
    The virtual columns order is changed after adding a new virtual column
    before old virtual column. And this is not support for inplace alter
    table. And we modified a bogus assertion also.
    
    Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
    RB: 11000

commit 3fd923ebf6609a0827ac1e90772350037f69a1b2
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Tue Nov 10 10:41:17 2015 +0100

    Fixed copyright year in CMakeLists.txt

commit 33b43322507424656ac7ac432bfb8704e5ebbf3b
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Tue Sep 15 15:26:22 2015 +0200

    Fixed some incomplete copyright headers
    
    (cherry picked from commit 54e6acf09c779a10d22891ba9716e27e6901caee)

commit 9060b8da69fb04681a274eee8ae6c7361270179f
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Tue Sep 15 15:22:22 2015 +0200

    Delete unwanted test plugins from docker rpm
    
    (cherry picked from commit b9a2d31674774c938f18f660fa733ce7537758b6)

commit b431058eeac316a52137ccb65711ffb67324c600
Author: Marko Mäkelä <marko.makela@oracle.com>
Date:   Tue Nov 10 08:23:34 2015 +0200

    Bug#22131684 INNODB: UNALIGNED 64-BIT MEMORY ACCESS ON 32-BIT SYSTEMS
    
    ut_allocator<T> was prepending the allocation payload with a 12-byte
    header on 32-bit systems, causing unaligned memory access.
    On 32-bit SPARC, this would cause a crash during bootstrap,
    because the std instruction (store double) expects 64-bit aligned memory.
    
    ut_new_pfx_t::pad: Pad the structure to 16 bytes (2*64 bits)
    on 32-bit systems. It is 24 bytes (3*64 bits) on 64-bit systems.
    
    RB: 10989
    Reviewed-by: Kevin Lewis <kevin.lewis@oracle.com>

commit 723efb5e90a5533b1e60fc6227c024486924354e
Author: Xing Zhang <xing.z.zhang@oracle.com>
Date:   Tue Nov 10 02:29:37 2015 +0100

    Bug#21974321: WEIGHT_STRING RESULT IS WRONG IF USED IN A VIEW (AS CHAR CLAUSE IS LOST)
    
    In WEIGHT_STRING, string can be casted before calculating its
    weight. String is casted to binary with Item_char_typecast. But
    the cast info is lost when the casting happends when it is not
    cast to binary.
    Solution: add virtual function print() to help
    Item_func_weight_string store cast info.

commit 8d91476c0b2bc510729a786ab3ba98ef6d28c2aa
Author: Christopher Powers <chris.powers@oracle.com>
Date:   Fri Nov 6 17:44:58 2015 -0600

    Bug#21935106 SHOW SESSION VARIABLES RECENTLY HAVING LOCK ISSUES
    
    The function alloc_and_copy_thd_dynamic_variables() synchronizes
    session variables with global variables. As of Bug#21840950, it uses
    the mutex THD::LOCK_thd_sysvar to block remote threads from accessing
    session vars during updates.
    
    With SHOW_COMPATIBILITY_56=OFF, SHOW VARIABLES can cause
    LOCK_thd_sysvar to be taken twice, first in System_variable::init()
    and later in alloc_and_copy_thd_dynamic_variables().
    
    System_variables::init() now only acquires LOCK_thd_sysvar if the
    target thread is not the current thread.
    
    perfschema.show_plugin.test is now two tests so that
    alloc_and_copy_thd_dynamic_variables() can be tested separately
    with SHOW_COMPATIBILITY_56 = ON and OFF.

commit b7da1efa93b516c4c56e83cfe0c66d22a26a0f7b
Merge: b27ac26 39a430e
Author: Mikhail Izioumtchenko <michael.izioumtchenko@oracle.com>
Date:   Mon Nov 9 22:10:57 2015 +0100

    Merge branch 'mysql-5.6' into mysql-5.7

commit b27ac2645384bca38524e8972155f58d5e0fa1ad
Author: Mikhail Izioumtchenko <michael.izioumtchenko@oracle.com>
Date:   Mon Nov 9 22:04:41 2015 +0100

    remove n test, nowadays it has its own repository

commit 39a430e785a0bedaea8287f4a6cb809b18cb6f2b
Author: Mikhail Izioumtchenko <michael.izioumtchenko@oracle.com>
Date:   Mon Nov 9 22:04:41 2015 +0100

    remove n test, nowadays it has its own repository

commit b216f09cbc3ec03c8c4ba9bbf8b1b31bd8d8ce34
Author: Kevin Lewis <kevin.lewis@oracle.com>
Date:   Wed Nov 4 16:37:20 2015 -0600

    Windows warning cleanup - 5.7
    
    casts and type changes in order to eliminate warnings on
    Windows 32 and 64 bit builds in InnoDB
    
    Approved by Jimmy in b10898

commit 4481b67cc1b000c6a6e39214dedda3db2cfceff2
Merge: 5e216db 09eba96
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Nov 9 15:31:47 2015 +0100

    Raise version number after cloning 5.7.10

commit 09eba96242103471dcb3e8512c0cbd478201b7f9
Merge: 94e193c c848ba1
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Nov 9 15:28:27 2015 +0100

    Raise version number after cloning 5.6.28

commit c848ba1c1adad3792a57cb412e84c3828a652d67
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon Nov 9 15:25:01 2015 +0100

    Raise version number after cloning 5.5.47
