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 1d31f5b3090d129382b50b95512f2f79305715a1
Author: Thayumanavar S <thayumanavar.x.sachithanantha@oracle.com>
Date:   Mon Jun 20 11:35:43 2016 +0530

    BUG#23080148 - BACKPORT BUG 14653594 AND BUG 20683959 TO
                   MYSQL-5.5
    
    The bug asks for a backport of bug#1463594 and bug#20682959. This
    is required because of the fact that if replication is enabled, master
    transaction can commit whereas slave can't commit due to not exact
    'enviroment'. This manifestation is seen in bug#22024200.

commit bbcde839669e510f390ff0571c597e59833a1d0c
Author: Terje Rosten <terje.rosten@oracle.com>
Date:   Thu May 19 15:58:35 2016 +0200

    BUG#17903583 MYSQL-COMMUNITY-SERVER SHOULD NOT DEPEND ON MYSQL-COMMUNITY-CLIENT (#70985)
    
    Fix is a backport of BUG#18518216/72230 to MySQL 5.5 and 5.6.
    
    Will also resolve:
    
     BUG#23605713/81384 LIBMYSQLCLIENT.SO.18 MISSING FROM MYSQL 5.7
    
      as mysql-community-libs-5.5 or mysql-community-libs-5.6 can
      installed on EL6 system with libmysqlclient.16 (from MySQL 5.1)
      libmysqlclient.20 (from MySQL 5.7) by doing:
    
      $ rpm --oldpackage -ivh mysql-community-libs-5.5.50-2.el6.x86_64.rpm
    
      Providing a way to have several versions of libmysqlclient installed
      on the same system.
    
    and help:
    
     BUG#23088014/80981 LIBS-COMPAT RPMS SHOULD BE INDEPENDENT OF ALL OTHER SUBPACKAGES
    
      due to less strict coupling between -libs-compat and -common package.

commit b31ebac9cdf86d11fa72016a07ce9e1224cf3590
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Fri Jun 17 10:11:33 2016 +0530

    Bug#23498283 - BUFFER OVERFLOW
    
    DESCRIPTION
    ===========
    Buffer overflow is reported in Regex library. This can be
    triggered when the data corresponding to argv[1] is >=
    512 bytes resutling in abnormal behaviour.
    
    ANALYSIS
    ========
    Its a straight forward case of SEGFAULT where the target
    buffer is smaller than the source string to be copied.
    A simple pre-copy validation should do.
    
    FIX
    ===
    A check is added before doing strcpy() to ensure that the
    target buffer is big enough to hold the to-be copied data.
    If the check fails, the program aborts.

commit ca3b739d1fb9948588ba53e84563e7208d289463
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Fri Jun 3 12:50:23 2016 +0530

    Bug#23035296: MAIN.MYSQLDUMP FAILS BECUASE OF UNEXPECTED
                  ERROR MESSAGE
    
    Post push patch to fix test case failure.

commit f633873d984a54a6984355893fe9d5a86f934a26
Merge: 199b1f6 eb7f682
Author: Prashant Tekriwal <prashant.tekriwal@oracle.com>
Date:   Thu Jun 2 12:44:54 2016 +0200

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

commit 199b1f61c8ff69727e40cd33e8a3cafa8177e232
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Thu Jun 2 15:02:46 2016 +0530

    Bug#23035296: MAIN.MYSQLDUMP FAILS BECUASE OF UNEXPECTED
                  ERROR MESSAGE
    
    Post push patch to fix test case failure.

commit e9aab33ca90443d3d5f0e4e444137ec2a3517f84
Author: Arun Kuruvila <arun.kuruvila@oracle.com>
Date:   Mon May 30 15:20:08 2016 +0530

    Bug#23035296: MAIN.MYSQLDUMP FAILS BECUASE OF UNEXPECTED
                  ERROR MESSAGE
    
    Description:- Mtr test, "main.mysqldump" is failing with an
    assert when "mysqlimport" client utility is executed with
    the option "--use_threads".
    
    Analysis:- "mysqlimport" uses the option, "--use_threads",
    to spawn worker threads to complete its job in parallel. But
    currently the main thread is not waiting for the worker
    threads to complete its cleanup, rather just wait for the
    worker threads to say its done doing its job. So the cleanup
    is done in a race between the worker threads and the main
    thread. This lead to an assertion failure.
    
    Fix:- "my_thread_join()" is introduced in the main thread to
    join all the worker threads it have spawned. This will let
    the main thread to wait for all the worker threads to
    complete its cleanup before calling "my_end()".

commit 61e47556284d0a076cc576d8f5b7e1bde73032fa
Author: Sreeharsha Ramanavarapu <sreeharsha.ramanavarapu@oracle.com>
Date:   Tue May 24 07:44:21 2016 +0530

    Bug #23279858: MYSQLD GOT SIGNAL 11 ON SIMPLE SELECT
                   NAME_CONST QUERY
    
    ISSUE:
    ------
    Using NAME_CONST with a non-constant negated expression as
    value can result in incorrect behavior.
    
    SOLUTION:
    ---------
    The problem can be avoided by checking whether the argument
    is a constant value.
    
    The fix is a backport of Bug#12735545.

commit b2c0b7bbb0359c767462aa71722f67fca11dbe8f
Author: Terje Rosten <terje.rosten@oracle.com>
Date:   Fri May 20 11:33:18 2016 +0200

    BUG#20693338 CONFLICTS WHILE INSTALLING PACKAGES WHEN LIBMYSQLCLIENT-DEVEL INSTALLED
    
    Remove mysql_config from client package to avoid conflict (file
    shipped in devel package any way).

commit b4a53c11ba8c20d99f404af99d22d6026d1fe752
Author: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Date:   Wed May 18 17:23:16 2016 +0530

    BUG#21879694 - /VAR/LOG/MYSQLD.LOG HAS INCORRECT PERMISSIONS AFTER INSTALLING SERVER FROM REPO
    
    Description:
    This issue doesn't effect any default installation of repo rpms if user uses
    init scripts that are shipped as part of package but will have trouble if
    user tries to createdb or start server manually.
    
    After installing mysql-server from repository(yum,zypper) /var/log/mysqld.log
    is created with logged in user and group permissions instead of with mysql
    user and group permissions,due to which while creating database or starting
    server, it is failing
    
    Fix:
    
    Updated the user and group permissions of the /var/log/mysqld.log and
    /var/log/mysql/mysqld.log (for sles) files to mysql.

commit 831bf7a8575b867f1b03004e36d3ffb0cf1db295
Author: Karthik Kamath <karthik.kamath@oracle.com>
Date:   Wed May 18 11:07:29 2016 +0530

    BUG#21142859: FUNCTION UPDATING A VIEW FAILS TO FIND TABLE
                  THAT ACTUALLY EXISTS
    
    ANALYSIS:
    =========
    Stored functions updating a view where the view table has a
    trigger defined that updates another table, fails reporting
    an error that the table doesn't exist.
    
    If there is a trigger defined on a table, a variable
    'trg_event_map' will be set to a non-zero value after the
    parsed tree creation. This indicates what triggers we need to
    pre-load for the TABLE_LIST when opening an associated table.
    
    During the prelocking phase, the variable 'trg_event_map'
    will not be set for the view table. This value will be set
    after the processing of triggers defined on the table. During
    the processing of sub-statements, 'locked_tables_mode' will be
    set to 'LTM_PRELOCKED' which denotes that further locking
    of tables/functions cannot be done. This results in the other
    table not being locked and thus further processing results in
    an error getting reported.
    
    FIX:
    ====
    During the prelocking of view, the value of 'trg_event_map'
    of the view is copied to 'trg_event_map' of the next table
    in the TABLE_LIST. This results in the locking of tables
    associated with the trigger as well.

commit 3487e20959c940cbd24429afa795ebfc8a01e94f
Author: Shishir Jaiswal <shishir.j.jaiswal@oracle.com>
Date:   Mon May 16 13:46:49 2016 +0530

    Bug#21977380 - POSSIBLE BUFFER OVERFLOW ISSUES
    
    DESCRIPTION
    ===========
    Buffer overflow is reported in a lot of code sections
    spanning across server, client programs, Regex libraries
    etc. If not handled appropriately, they can cause abnormal
    behaviour.
    
    ANALYSIS
    ========
    The reported casea are the ones which are likely to result
    in SEGFAULT, MEMORY LEAK etc.
    
    FIX
    ===
    - sprintf() has been replaced by my_snprintf() to avoid
    buffer overflow.
    - my_free() is done after checking if the pointer isn't
      NULL already and setting it to NULL thereafter at few
      places.
    - Buffer is ensured to be large enough to hold the data.
    - 'unsigned int' (aka 'uint') is replaced with 'size_t'
    to avoid wraparound.
    - Memory is freed (if not done so) after its alloced and
    used.
    - Inserted assert() for size check in InnoDb memcached
    code (from 5.6 onwards)
    - Other minor changes

commit e3fea6c6dbb36c6ab21c4ab777224560e9608b53
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Fri May 13 16:42:45 2016 +0530

    Bug#23251517: SEMISYNC REPLICATION HANGING
    
    Revert following bug fix:
    
    Bug#20685029: SLAVE IO THREAD SHOULD STOP WHEN DISK IS
    FULL
    Bug#21753696: MAKE SHOW SLAVE STATUS NON BLOCKING IF IO
    THREAD WAITS FOR DISK SPACE
    
    This fix results in a deadlock between slave IO thread
    and SQL thread.

commit d91f1d4e32777af0da498818c8098d45c6f64bac
Author: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
Date:   Wed May 4 14:06:45 2016 +0530

    Bug#12818255: READ-ONLY OPTION DOES NOT ALLOW
    INSERTS/UPDATES ON TEMPORARY TABLES
    Bug#14294223: CHANGES NOT ALLOWED TO TEMPORARY TABLES ON
    READ-ONLY SERVERS
    
    Problem:
    ========
    Running 5.5.14 in read only we can create temporary tables
    but can not insert or update records in the table. When we
    try we get Error 1290 : The MySQL server is running with the
    --read-only option so it cannot execute this statement.
    
    Analysis:
    =========
    This bug is very specific to binlog being enabled and
    binlog-format being stmt/mixed. Standalone server without
    binlog enabled or with row based binlog-mode works fine.
    
    How standalone server and row based replication work:
    =====================================================
    Standalone server and row based replication mark the
    transactions as read_write only when they are modifying
    non temporary tables as part of their current transaction.
    
    Because of this when code enters commit phase it checks
    if a transaction is read_write or not. If the transaction
    is read_write and global read only mode is enabled those
    transaction will fail with 'server is read only mode'
    error.
    
    In the case of statement based mode at the time of writing
    to binary log a binlog handler is created and it is always
    marked as read_write. In case of temporary tables even
    though the engine did not mark the transaction as read_write
    but the new transaction that is started by binlog handler is
    considered as read_write.
    
    Hence in this case when code enters commit phase it finds
    one handler which has a read_write transaction even when
    we are modifying temporary table. This causes the server
    to throw an error when global read-only mode is enabled.
    
    Fix:
    ====
    At the time of commit in "ha_commit_trans" if a read_write
    transaction is found, we should check if this transaction is
    coming from a handler other than binlog_handler. This will
    ensure that there is a genuine read_write transaction being
    sent by the engine apart from binlog_handler and only then
    it should be blocked.

commit 6bcced8bd30e45fd6c0bc03088bab71576bf8273
Author: Bjorn Munch <bjorn.munch@oracle.com>
Date:   Mon May 2 09:26:00 2016 +0200

    Raise version number after cloning 5.5.50
