commit 259f2ca9477c92b6e9a91cb37dac19d24ffcacd9
Author: Terje Rosten <terje.rosten@oracle.com>
Date:   Fri Aug 26 11:26:23 2016 +0200

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

commit cd9aa1d8f0d18c9cabe763ed4dfef17f7f6bd62e
Author: Sivert Sorumgard <sivert.sorumgaard@oracle.com>
Date:   Wed Aug 24 14:03:11 2016 +0200

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

commit 4dec730874c3669d3dfe6b42e8e10790993ab69b
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
Date:   Fri Aug 19 09:16:27 2016 +0200

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

commit 6c4c5c8cf205c4fae0182ce8e2c9f92a8bd43321
Author: Terje Rosten <terje.rosten@oracle.com>
Date:   Thu Aug 18 16:49:08 2016 +0200

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

commit e945f3b6e99d23c89dc9580885e4bf89ab006ccf
Author: Deepa Dixit <deepa.dixit@oracle.com>
Date:   Fri Aug 5 16:09:51 2016 +0530

    Bug#22818781: EXPLAIN_JSON_VALIDATE.TEST FAILS ON WINDOWS PRE-PUSH TESTING
    
    Issue:
    ------
    The explain_json_validate test calls a python script which accepts arguments.
    If the arguments are passed with wildcard characters, Windows cannot parse
    them and hence the test fails.
    
    Fix:
    ----
    The fix involved adding an additional check if the test was running on Windows
    so that the arguments can be parsed correctly.
    Also, Python is not installed on Windows by default, and therefore the
    script is now ported to perl. Before the test used to be skipped if the machine
    did not have either Python or JSON support, but now it fails if it does not
    have JSON or perl support.
    Since the python script has been removed, all the tests which were using that
    script are now using the perl script.
    
    Reviewed-by: Horst Hunger <horst.hunger@oracle.com>
    Reviewed-by: Guilhem Bichot <guilhem.bichot@oracle.com>
    RB: 12537

commit 63a16c346f535990309f9985ffc4aabf1fe6cd5e
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Fri Aug 5 09:05:18 2016 +0200

    BUG#23760086 INNODB: ASSERTION FAILURE: MACH0DATA.IC:56:(N | 0XFFFFUL)
    <= 0XFFFFUL
    
    Analysis: In row_log_table_delete(), extern size could be greater
    than 2 bytes int if there are enough index on blob columns.
    
    Solution: Use 4 bytes int other than 2 bytes for extern size.
    
    Reviewed-by: Marko Mäkelä <marko.makela@oracle.com>
    RB: 13573

commit e20773a9cc7f5a0754fd0448836af1f37297cfdb
Merge: 8a9431a b3e3e9c
Author: Neha Kumari <neha.n.kumari@oracle.com>
Date:   Fri Aug 5 12:34:21 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit b3e3e9c7ed5526dff4f0bc222e674239b352ee27
Author: Neha Kumari <neha.n.kumari@oracle.com>
Date:   Fri Aug 5 12:17:11 2016 +0530

    Bug#23540182:MYSQLBINLOG DOES NOT FREE THE EXISTING CONNECTION BEFORE OPENING NEW REMOTE ONE
    
    It happens when you are trying to read two or more log files from a
    remote server using mysqlbinlog utility.
    
    The reason for this is no matching mysql_close() that concludes the
    life time of 'mysql' struct describing connection to the server.
    This happens when mysqlbinlog is invoked with connecting to the server
    and requesting more than one binlog file. In such case
    dump_remote_log_entries() keeps calling safe_connect() per eachfile,
    never caring to invoke mysql_close(). Only the final safe_connect()'s
    allocation effect are cleaned by the base code.
    That is with 2 files there's one 'mysql' connection descriptor struct
    uncleaned/deallocated.
    
    We are backporting the bug 21255763 (pushed in mysql-trunk)
    in the earlier version of MySQL starting from 5.5 to 5.7.
    which was pushed in mysql-trunk.
    
    Fix:
    Invoke mysql_close() just before mysql_init() in safe_connect()
    defined in mysqlbinlog.cc. That makes possibly previously used 'mysql' be
    reclaimed prior a new one is allocated.

commit 8a9431a180225f1aeb8238ffcc1a6deebfba1f25
Merge: c32616e 3cde802
Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
Date:   Thu Aug 4 12:50:48 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 3cde80250f0592cf4270986f28946fdb1d440fc4
Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
Date:   Thu Aug 4 12:49:50 2016 +0530

    Bug #19984392 : MEDIUMINT: STACK BUFFER OVERFLOW IN PROTOCOL_TEXT::STORE_LONG
    
    Reverting the patch due to some issues.

commit c32616e41ad7b4f5dbe5fbdee44fd8be686f8d04
Merge: ee675f2 c3743ff
Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
Date:   Wed Aug 3 12:57:38 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit c3743ff9b7813e9942d11ae8856a1732f830c941
Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
Date:   Wed Aug 3 12:54:58 2016 +0530

    Bug #19984392 : MEDIUMINT: STACK BUFFER OVERFLOW IN PROTOCOL_TEXT::STORE_LONG
    
    ISSUE: Queries with mediumint as column when operated with
    long long type of data results in buffer overflow in
    store_long function.
    
    The merging rule specified for (MYSQL_TYPE_LONGLONG
    MYSQL_TYPE_INT24) is MYSQL_TYPE_LONG. Due to this store_long
    function was getting called which resulted in buffer overflow.
    
    SOLUTION:
    The correct merging rule for (MYSQL_TYPE_LONGLONG,
    MYSQL_TYPE_INT24) should be MYSQL_TYPE_LONGLONG.
    So, instead of function store_long, function store_longlong
    is called which correctly handles the type MYSQL_TYPE_LONGLONG.
    
    External Bug #23645238 is a duplicate of this issue.

commit ee675f2d77915b7ebc55cd7e90365581261f90ff
Merge: 6a9abb6 2a774df
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Aug 3 09:59:37 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 2a774df598b8651897a4394e20ca2bfac6de2512
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Wed Aug 3 09:58:36 2016 +0530

    Bug #24380263: INCORRECT BEHAVIOR WITH PARAMETER AND
                   DERIVED TABLE IN JOIN
    
    ISSUE:
    ------
    This problem occurs under the following conditions:
    1) A parameter is used in the select-list of a derived table.
    2) The derived table is part of a JOIN.
    
    SOLUTION:
    ---------
    When a derived table is materialized, a temporary table is
    created. This temporary table creates a field each for the
    items in the select-list of the derived table. This set of
    fields is later used to setup the join.
    
    Currently no field is created in the temporary table if a
    parameter is used in the select-list.
    
    Create a field for the parameter. By default Item_param's
    result type in a prepared statement is set to
    STRING_RESULT. This can change during the execute phase
    depending on the user variable. But since the execute phase
    creates its own temporary table, it will be handled
    separately.
    
    This is a backport of the fix for BUG#22392374.

commit 6a9abb618aebb0624eb307a0f9f58604047e01c8
Author: Srikanth B R <srikanth.b.r@oracle.com>
Date:   Mon Aug 1 18:53:44 2016 +0530

    Bug#22342399: MTR LIMITS PARALLEL TESTS TO 50
    
    Issue:
    ------
    The number of parallel workers in mysql-test-run has an artificial
    limit of 50. On some hardware, more CPU's are present and having
    --parallel > 50 leads to MTR running out of unique build thread ids
    as it has a hard-coded upper limit(50 build thread id's) for them.
    
    Fix:
    ----
    The patch attached removes the arbitrary limit and sets the upper
    build thread limit based on the value given to --parallel. Two other
    small changes relevant for running with high parallel settings have
    been included:
    1)The number of parallel workers is now restricted to number of tests
      for avoiding idle workers.
    2)The maximum number of parallel workers was restricted to 8 for
      --parallel=auto in case the environment variable MTR_MAX_PARALLEL
      was not set. This restriction has been removed as it hinders MTR
      performance on powerful machines.
    
    Reviewed-by: Bjorn Munch <bjorn.munch@oracle.com>
    RB: 13472

commit 33b15f9f52214ad1663345e9f123ad613f6f4a28
Author: Srikanth B R <srikanth.b.r@oracle.com>
Date:   Mon Aug 1 18:31:13 2016 +0530

    Bug#23742016: MTR --PARALLEL=AUTO IS ALWAYS 1 ON OSX
    
    Issue:
    ------
    MTR currently checks for CPU information using '/proc/cpuinfo' on
    linux and 'kstat' on solaris. As no information can be obtained
    from them on OS-X, a dummy CPU is added and the number of CPU's is
    reported as 1 by default. Hence, using --parallel=auto leads to
    MTR running tests on a single worker.
    
    Fix:
    ----
    A routine has been added to get CPU information on OS-X using the
    'sysctl' command. The number of parallel MTR workers is set to the
    number of processors in the machine.
    
    Reviewed-by: Sayantan Dutta <sayantan.dutta@oracle.com>
    RB: 13389

commit 6ea08b4fa03d656873b816fca073f00170dfc7a2
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Mon Aug 1 13:23:31 2016 +0200

    Bug#24303829 ADD SUPPORT FOR SOLARIS STUDIO 12.5 AKA 5.14 TO MYSQL 5.6
    
    Additional patch for cmake version 2.8.12.2

commit f31d2752f2309fdafe550beb10381065991445ea
Merge: 6a86a16 f84c952
Author: Prashant Tekriwal <prashant.tekriwal@oracle.com>
Date:   Fri Jul 29 14:23:36 2016 +0200

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

commit 6a86a16ee00e275ff1d72472b9c1e61e7c36e9a0
Merge: e206e0a 3bc2b57
Author: Nawaz Nazeer Ahamed <nawaz.nazeer.ahamed@oracle.com>
Date:   Fri Jul 29 16:52:58 2016 +0530

    Upmerge of the 5.5.51 build

commit 3bc2b572967a4a67a6a3a0b41a0199f81d4339c4
Merge: a0738f7 0496931
Author: Nawaz Nazeer Ahamed <nawaz.nazeer.ahamed@oracle.com>
Date:   Fri Jul 29 16:46:56 2016 +0530

    Merge branch 'mysql-5.5.51-release' into mysql-5.5

commit e206e0a6e43790084070cf50617505ffbd19ab24
Author: Tor Didriksen <tor.didriksen@oracle.com>
Date:   Fri Jul 15 16:48:33 2016 +0200

    Bug#24303829 ADD SUPPORT FOR SOLARIS STUDIO 12.5 AKA 5.14 TO MYSQL 5.6
    
    Parse new output from 'CC -V'
    
    Remove '-Xa' from COMMON_C_FLAGS (prefer ISO C rather than K&R C semantics)
    It is not needed, and it cannot be used together with the -std=xxx flag.
    
    This is a partial backport of the fix for:
    Bug#23212938 ADD SUPPORT FOR SOLARIS STUDIO 12.5 AKA 5.14

commit 3044190d26089ad5cc54e229a58e41018a4debe0
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Jul 27 10:39:19 2016 +0200

    Followup: BUG#23479595 SEGMENTATION FAULT WHEN SELECT FTS INDEX
              TABLES IN INFORMATION SCHEMA
    
    BUG#23742339 FAILING ASSERTION: SYM_NODE->TABLE != NULL
    
    Analysis: When we access fts aux tables in information schema,the
    fts aux tables are dropped by DROP DATABASE in another session.
    
    Solution: Drop parent table if it's a fts aux table, and drop
    table will drop fts aux tables together.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 13264

commit 800b8766bde7353293b8784e604b60af20dacce5
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Jul 27 09:37:20 2016 +0200

    BUG#24315031 FAILING ASSERTION: !TABLE->CAN_BE_EVICTED
    
    Analysis:
    the old table is dropped, just after it's added into drop list,
    and new table with the same name is created, then we try to drop
    the new table in background.
    
    Solution:
    Don't drop a table in background if table->to_be_dropped is false.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 13414

commit c5728a8a29ed496c09c58751a860db9af962ae59
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Wed Jul 27 03:43:52 2016 +0200

    BUG#24009272 SEGFAULT WITH CREATE+SELECT FROM IS+DROP FTS TABLE
    CONCURRENTLY
    
    Analysis:
    When we access fts_internal_tbl_name in i_s_fts_config_fill (),
    it can be set to NULL by another session.
    
    Solution:
    Define fts_internal_tbl_name2 for global variable innodb_ft_aux_table,
    if it's NULL, set fts_internal_tbl_name to "default".
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 13401

commit 4d4c42e2ba8a44c9c7160ecf1192de8e635c0312
Author: Dmitry Lenev <dmitry.lenev@oracle.com>
Date:   Mon Jul 25 16:06:52 2016 +0300

    Fix for bug #16672723 "CAN'T FIND TEMPORARY TABLE".
    
    Attempt to execute prepared CREATE TABLE SELECT statement which used
    temporary table in the subquery in FROM clause and stored function
    failed with unwarranted ER_NO_SUCH_TABLE error. The same happened
    when such statement was used in stored procedure and this procedure
    was re-executed.
    
    The problem occurred because execution of such prepared statement/its
    re-execution as part of stored procedure incorrectly set
    Query_table_list::query_tables_own_last marker, indicating the last
    table which is directly used by statement. As result temporary table
    used in the subquery was treated as indirectly used/belonging to
    prelocking list and was not pre-opened by open_temporary_tables()
    call before statement execution. Thus causing ER_NO_SUCH_TABLE errors
    since our code assumes that temporary tables need to be correctly
    pre-opened before statement execution.
    
    This problem became visible only in version 5.6 after patches related to
    bug 11746602/27480 "EXTEND CREATE TEMPORARY TABLES PRIVILEGE TO ALLOW
    TEMP TABLE OPERATIONS" since they have introduced pre-opening of temporary
    tables for statements.
    
    Incorrect setting of Query_table_list::query_tables_own_last happened
    in LEX::first_lists_tables_same() method which is called by CREATE TABLE
    SELECT implementation as part of LEX::unlink_first_table(), which temporary
    excludes table list element for table being created from the query table
    list before handling SELECT part.
    
    LEX::first_lists_tables_same() tries to ensure that global table list of
    the statement starts with the first table list element from the first
    statement select. To do this it moves such table list element to the head
    of the global table list. If this table happens to be last directly-used
    table for the statement, query_tables_own_last marker is pointing to it.
    Since this marker was not updated when table list element was moved we
    ended up with all tables except the first table separated by it as if
    they were not directly used by statement (i.e. belonged to prelocked
    tables list).
    
    This fix changes code of LEX::first_lists_tables_same() to update
    query_tables_own_last marker in cases when it points to the table
    being moved. It is set to the table which precedes table being moved
    in this case.

commit 27dfa58cb07c6e58c2b58a673e18b7b824516c13
Merge: f470c10 a0738f7
Author: Neha Kumari <neha.n.kumari@oracle.com>
Date:   Mon Jul 25 21:20:52 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6
    And fixed conflicts.

commit a0738f703e20b5530fe319f47fc1e5c8ad9e9667
Author: Neha Kumari <neha.n.kumari@oracle.com>
Date:   Mon Jul 25 20:34:20 2016 +0530

    BUG#23509275 :DBUG_PRINT in THD::decide_logging_format prints incorrectly, access out-of-bound
    
    Problem:
    In debug builds, there is a chance that an out-of-bounds
    read is performed when tables are locked in
    LTM_PRELOCKED_UNDER_LOCK_TABLES mode. It can happen because
    the debug code uses enum values as index for an array of
    mode descriptions, but it only takes into consideration 3
    out of 4 of the enum values.
    
    Fix:
    This patch fixes it by implementing a getter for the enum which
    returns a string representation of the enum,
    effectively removing the out-of-bounds read.
    
    Moreover, it also fixes the lock mode descriptions that
    would be print out in debug builds.

commit f470c103b29250cedfd3a124f6f0dedcebab3e57
Merge: bc715f5 9c7309c
Author: Thayumanavar S <thayumanavar.x.sachithanantha@oracle.com>
Date:   Mon Jul 25 07:50:47 2016 +0200

    Merge branch 'mysql-5.5' into mysql-5.6

commit 9c7309c0d5bc1d663df96a730076d88f625a322c
Author: Thayumanavar S <thayumanavar.x.sachithanantha@oracle.com>
Date:   Mon Jul 25 06:43:16 2016 +0100

    BUG#23703568 -  IS CLIENT LIBRARY SUPPOSED TO RETRY EINTR INDEFINITELY OR NOT
    
    Commit#ebd24626ca38e7fa1e3da2acdcf88540be70fabe obsoleted the THREAD and
    THREAD_SAFE_CLIENT preprocessor symbols. This is not removed in the
    sql/net_serv.cc thereby the code that retries on EINTR became dead code.
    Remove the THREAD_SAFE_CLIENT preprocessor directive form sql/net_serv.cc.
    Also check errno for EINTR only if there is an error in preceding read call.

commit bc715f5e681ebafa2bf468ba030bcf2ee18f54a7
Merge: ab63d81 39a1f7d
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Fri Jul 22 13:17:41 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 39a1f7d8f19300c1e0f49f5db983b94ce3ae1854
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Fri Jul 22 13:15:32 2016 +0530

    Bug #23295288: HANDLE_FATAL_SIGNAL (SIG=11) IN
                   GET_SERVER_FROM_TABLE_TO_CACHE
    
    Description:- Server received SIG11 in the function,
    "get_server_from_table_to_cache()".
    
    Analysis:- Defining a server with a blank name is not
    handled properly.
    
    Fix:- Modified "get_server_from_table_to_cache()" to
    take care of blank server name.

commit ab63d814c81a50d586fff7b57dfe07ac10758333
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri Jul 22 10:55:25 2016 +0530

    Bug#22510353: UNNECESSARY USING TEMPORARY FOR UPDATE
    
    Problem:
    =======
    when the binlog_row_image is FULL, we set read_set and
    write_set all before update. This leads to setting
    used_key_is_modified true, which lead to mysql_update use
    temporary at last. Actually there is no need to use
    temporary in most cases. The root cause is that we set
    read_set and write_set too early.
    
    Analysis:
    =========
    As reported in problem description table's read_set and
    write_set are set earlier.
    'mark_columns_per_binlog_row_image' is the function call
    which sets these read and write sets. But this is called
    at an earlier stage during execution and in the case of
    binlog_row_image=FULL it will set all the bits of read and
    write sets. This will make the update query to think that
    a key is being modified by the existing update query. Even
    though it is not modifying the key field. This will force
    the update query to use a temporary table even though it may
    not be required. The same problem exists even in the case of
    binlog_row_image=NOBLOB. This problem is specific to single
    table updates.
    
    This issue is not present in the case of multi table update.
    As in the multi table update case, the check for 'used key
    is modified or not' is done before marking
    read_set/write_set as per binlog_row_image. Hence binary log
    specific bits are not influencing query to use temporary
    table.
    
    Fix:
    ===
    Implemented single table update to follow the same mechanism
    that multi table update follows. i.e Mark the columns in
    table's read_set/write_set as the binlog_row_image after the
    'used key is modified or not' decision is taken.

commit 926ec9c656582bcbc2e69087eeb11a1c197ac717
Merge: 74cfd7c 8235e91
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Jul 22 07:35:57 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 8235e9184c5a0cab08d74dfa4d47ff0faed8c31a
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Fri Jul 22 07:33:43 2016 +0530

    Bug #23280699: MYSQLD GOT SIGNAL 11 IN IS_NULL ON SELECT
                   FROM I_S
    
    Issue:
    ------
    There is a difference in the field type created when the
    following DDLs are used:
    
    1) CREATE TABLE t0 AS SELECT NULL;
    2) CREATE TABLE t0 AS SELECT GREATEST(NULL,NULL);
    
    The first statement creates field of type Field_string and
    the second one creates a field of type Field_null.
    
    This creates a problem when the query mentioned in this bug
    is used. Since the null_ptr is calculated differently for
    Field_null.
    
    Solution:
    ---------
    When there is a function returning null in the select list
    as mentioned above, the field should be of type
    Field_string.
    
    This was fixed in 5.6+ as part of Bug#14021323. This is a
    backport to mysql-5.5.
    
    An incorrect comment in innodb_bug54044.test has been
    corrected in all versions.

commit 74cfd7cfab19ea0d0bc52c7cab3616ef8165f4bc
Merge: efd84b4 a9911d0
Author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
Date:   Tue Jul 19 08:04:29 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit a9911d0b31e874c7ad6d3f088e755e04beb49e38
Author: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
Date:   Tue Jul 19 08:03:09 2016 +0530

    Bug#23280059: ITEM_ROW::ILLEGAL_METHOD_CALL(CONST CHAR*):
    	      ASSERTION `0' FAILED ON SELECT AREA
    
    Problem:
    Optimizer tries to get the points to calculate area without
    checking the return value of uint4korr for 0 "points". As a
    result server exits.
    
    Solution:
    Check the return value from uint4korr().

commit efd84b4bcba3516e15699be833f1292670144e22
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri Jul 15 14:39:37 2016 +0530

    Bug #23475211	COMBINING ALTER OPERATIONS TRIGGERS TABLE REBUILD
    
    Problem:
    =======
    Inplace alter algorithm determines the table to be rebuild if the table
    undergoes row format change, key block size if handler flag contains only
    change table create option. If alter with inplace ignore flag operations and change table create options then it leads to table rebuild operation.
    
    Solution:
    ========
    During the check for rebuild, ignore the inplace ignore flag and check for
    table create options.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    Reviewed-by: Marko Makela <marko.makela@oracle.com>
    RB: 13172

commit 47c0fdfced7f5bb5e1ae9af9bdaeb369b5f8583b
Author: Georgi Kodinov <georgi.kodinov@oracle.com>
Date:   Thu Jul 7 15:37:25 2016 +0300

    Bug #23747899: @@BASEDIR SYSVAR VALUE NOT NORMALIZED IF SET THROUGH
      THE COMMAND LINE/INI FILE
    
    The system variable basedir is of type charptr and can take command line
    arguments. This means that it operates on a "char *" global and every time
    a command line argument is supplied a new string buffer is allocated and
    assigned to this variable.
    The global char * used for this variable is called base_dir_ptr.
    Originally this char * is assigned to a global char array called base_dir.
    And the rest of the server code uses the base_dir array directly.
    But setting a new value on the command line set the base_dir_ptr to the
    something different than the base_dir.
    Then, in mysqld_get_one_option(), the contents of that new buffer is copied
    to base_dir, but the base_dir_ptr is not reset to point back to base_dir.
    Thus it does not reflect the subsequent processing done directly over base_dir
    This processing includes (among other things) normalization of the path
    separators used. As a result the system variable returns the data exactly as
    set on the command line or through the INI file instead of the normalized
    value that's stored in base_dir.
    
    Note that no other code uses base_dir_ptr, thus the problem is constrained
    to the value returned for @@basedir.
    
    Fixed by reseting base_dir_ptr to point to base_dir in mysqld_get_one_option
    right after copying the new value back. This makes it similar to the other
    path containing system variables.
    
    Test case added.

commit ae4d5db19450380f448b0763d97a3a98277704b4
Author: Srikanth B R <srikanth.b.r@oracle.com>
Date:   Mon Jul 11 10:14:23 2016 +0530

    Bug#23060553 MTR SPAWNS ONLY ONE WORKER WHEN USING --PARALLEL=AUTO
                 ON WINDOWS
    
    Follow-up fix: Restoring original file permissions of mysql-test-run.pl
    
    Reviewed by: Erlend Dahl <erlend.dahl@oracle.com>

commit b587f4a2531b20b4f15792527fa0b46fc5138dde
Author: Srikanth B R <srikanth.b.r@oracle.com>
Date:   Fri Jul 8 14:33:55 2016 +0530

    Bug#23060553 MTR SPAWNS ONLY ONE WORKER WHEN USING --PARALLEL=AUTO
                 ON WINDOWS
    
    Issue:
    ------
    MTR does not compute the number of parallel workers when the option
    --parallel=auto is given on Windows and spawns only one worker by
    default. An additional check throttles the number of parallel workers
    to one in case of virtual machines on Windows.
    
    Fix:
    ----
    Number of parallel MTR workers is now set to the number of processors
    using the environment variable 'NUMBER_OF_PROCESSORS' when --parallel
    =auto is given on Windows. Also, a line which checks if a Windows machine
    is a virtual one and sets the --parallel value to one has been removed
    as Windows VM's are stable with huge amount of threads these days.
    
    Reviewed-by:
    Sayantan Dutta <sayantan.dutta@oracle.com>
    RB #12523

commit 04969317137464074556c969950d3782f551fbdf
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Tue Jul 5 17:08:37 2016 +0530

    Bug#23736787 - YUM UPDATE FAIL FROM 5.5.51(COMUNITY/COMMERCIAL) TO 5.6.32(COMUNITY/COMMERCIAL)
    
    Remove mysql_config from client sub-package
    
    (cherry picked from commit 45c4bfa0f3f1c70756591f48710bb3e76ffde9bc)

commit c45124a0b582d57ac6cf20b786e0c643ec9ce941
Author: Shaohua Wang <shaohua.wang@oracle.com>
Date:   Thu Jul 7 11:41:31 2016 +0800

    Followup: BUG#23479595 SEGMENTATION FAULT WHEN SELECT FTS INDEX
              TABLES IN INFORMATION SCHEMA
    
    BUG#23742339 FAILING ASSERTION: SYM_NODE->TABLE != NULL
    
    Problem: When we access fts aux tables in information schema,the
    fts aux tables are dropped by DROP DATABASE in another session.
    
    Solution: Block DDL by s-locking dict_operation_lock.
    
    Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
    RB: 13264

commit 308f9b88e75f6179add209a2fe6affdb49b7c2ee
Merge: 140d08c 45c4bfa
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Tue Jul 5 17:12:56 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 45c4bfa0f3f1c70756591f48710bb3e76ffde9bc
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Tue Jul 5 17:08:37 2016 +0530

    Bug#23736787 - YUM UPDATE FAIL FROM 5.5.51(COMUNITY/COMMERCIAL) TO 5.6.32(COMUNITY/COMMERCIAL)
    
    Remove mysql_config from client sub-package

commit 140d08cf1d8c7dee9cd3531860c0853af372bbca
Merge: f262d5a 43320b7
Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
Date:   Fri Jul 1 12:05:29 2016 +0530

    Merge branch 'mysql-5.5' into mysql-5.6

commit 43320b72495cccc24fbe2a83fe4844f93bac6a08
Author: Kailasnath Nagarkar <kailasnath.nagarkar@oracle.com>
Date:   Fri Jul 1 12:01:27 2016 +0530

    Bug #23296299 : HANDLE_FATAL_SIGNAL (SIG=11) IN
                    MY_TOSORT_UTF32
    
    This patch is specific for mysql-5.5
    
    ISSUE: When a charater that is larger than possible to
    handle is passed to function my_tosort_utf32(), it results
    in segmentation fault. In the scenario mentioned in the bug
    AES_ENCRYPT function is used which returns large value.
    This value is further passed to my_tosort_utf32 function.
    This causes to cross array bound for array uni_plane,
    resulting in segment violation.
    
    SOLUTION:
    This issue has got addressed in 5.6 onward releases
    through worklog 2673.
    
    The fix is similar backport of that.
    Check for maximum character before accessing the array
    uni_plane. In addition to function my_tosort_utf32, the
    same potential problem is also present in functions
    my_tolower_utf16, my_toupper_utf16, my_tosort_utf16,
    my_tolower_utf32, my_toupper_utf32, my_tosort_unicode,
    my_tolower_utf8mb4 and my_toupper_utf8mb4.
    Fixed these functions as well.

commit f262d5acb164853acf3d9f6a1a296b6f6eb00e40
Merge: 86b2481 09f089b
Author: Christopher Powers <chris.powers@oracle.com>
Date:   Thu Jun 30 20:57:29 2016 +0200

    Merge branch 'mysql-5.5' into mysql-5.6

commit 09f089bfb9f1b95a2da6129313b3e03229620810
Author: Christopher Powers <chris.powers@oracle.com>
Date:   Thu Jun 30 20:42:29 2016 +0200

    Bug#14111584 PB2: PERFSCHEMA.AGGREGATE FAILS ON PB2 SPORADICALLY
    
    Permanently removed test case perfschema.aggregate.
    
    The Performance Schema is generally lock-free, allowing for
    race conditions that might arise from multi-threaded operation
    which occasionally results in temporary and/or minor variances
    when aggregating statistics. This test needs to be redesigned
    to accommodate such variances.

commit 86b24811e1a1f75d6580a2cb2e7aba8499df7b3c
Merge: 32df078 722ab50
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Mon Jun 27 12:52:39 2016 +0530

    Raise version number after cloning 5.6.32

commit 722ab50d01a795895a6ca8f13b3409b1919f16c0
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Mon Jun 27 12:48:57 2016 +0530

    Raise version number after cloning 5.5.51
