------------------------------------------------------------
revno: 6130
committer: Georgi Kodinov <georgi.kodinov@oracle.com>
branch nick: mysql-5.6.21-release
timestamp: Thu 2014-09-11 16:27:20 +0300
message:
  Bug #19588329: DH KEY GENERATION IN ENTERPRISE ENCRYPTION NOT USABLE
  
  (merge to the 5.6.21 tree)
  
   Problem: To compute a shared symmetric secret using
                 DH algorithm, keys of both the parties need to be
                 generated with same parameters.
                 ASYMMETRIC_DERIVE function provided in the UDF
                 openssl_udf is unusable as there is no way one can
                 provide parameters during the creation of
                 private key.
  
        Solution: Added a function CREATE_DH_PARAMETERS which
                  generates and returns DH parameters as a string.
                  The same can be used as an argument in
                  CREATE_ASYMMETRIC_PRIV_KEY and key can be
                  generated. CREATE_ASYMMETRIC_PRIV_KEY is also
                  modified to support this behaviour for DH.
------------------------------------------------------------
revno: 6129
committer: MySQL Build Team <mysql-build@oss.oracle.com>
branch nick: mysql-5.6.21-release
timestamp: Mon 2014-09-08 12:33:48 +0200
message:
  bug19471516 for mysql-5.6
------------------------------------------------------------
revno: 6128
committer: Vishal Chaudhary <vishal.chaudhary@oracle.com>
branch nick: mysql-5.6.21-release
timestamp: Thu 2014-09-04 07:45:16 +0200
message:
  WL#7717 Expose the SSL library encryption functions to SQL
------------------------------------------------------------
revno: 6127
committer: Vishal Chaudhary <vishal.chaudhary@oracle.com>
branch nick: mysql-5.6.21-release
timestamp: Wed 2014-08-27 15:52:25 +0200
message:
  patch for 19506247-fedora builds
------------------------------------------------------------
revno: 6126
committer: Vishal Chaudhary <vishal.chaudhary@oracle.com>
branch nick: mysql-5.6.21-release
timestamp: Tue 2014-08-26 15:13:47 +0200
message:
  Rename enterprise repo packages to commercial
------------------------------------------------------------
revno: 6125 [merge]
tags: clone-5.6.21-build
committer: Harin Vadodaria <harin.vadodaria@oracle.com>
branch nick: 5.6
timestamp: Sat 2014-08-23 09:04:14 +0530
message:
  Bug#19370676 : YASSL PRE-AUTH BUFFER OVERFLOW WHEN CLIENT
                 LIES ABOUT SUITE_LEN_
                 and
  Bug#19355577 : YASSL PRE-AUTH BUFFER OVERFLOW WHEN CLIENT
                 LIES ABOUT COMP_LEN_
  
  Description : Merge from 5.5 to 5.6
    ------------------------------------------------------------
    revno: 2875.468.97
    tags: clone-5.5.40-build
    committer: Harin Vadodaria <harin.vadodaria@oracle.com>
    branch nick: 5.5
    timestamp: Sat 2014-08-23 08:59:03 +0530
    message:
      Bug#19370676 : YASSL PRE-AUTH BUFFER OVERFLOW WHEN CLIENT
                     LIES ABOUT SUITE_LEN_
                     and
      Bug#19355577 : YASSL PRE-AUTH BUFFER OVERFLOW WHEN CLIENT
                     LIES ABOUT COMP_LEN_
      
      Description : Updating yaSSL to version 2.3.4.
------------------------------------------------------------
revno: 6124
committer: bin.x.su@oracle.com
branch nick: mysql-5.6
timestamp: Fri 2014-08-22 19:54:02 +0800
message:
  Revert the push(rev:6120) of
  Bug#19450143 - BUF_READ_PAGE_ASYNC CALLS BUF_READ_PAGE_LOW WITH SYNC=TRUE,
  since some test case failure needs to be fixed.
------------------------------------------------------------
revno: 6123 [merge]
committer: Tor Didriksen <tor.didriksen@oracle.com>
branch nick: 5.6-merge
timestamp: Thu 2014-08-21 17:05:57 +0200
message:
  Bug#18928848 II. MALLOC OF UNINITIALIZED MEMORY SIZE
  
  Merge 5.5=> 5.6
  fix merge conflicts
    ------------------------------------------------------------
    revno: 2875.468.96
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.5
    timestamp: Thu 2014-08-21 16:42:04 +0200
    message:
      Bug#18928848 II. MALLOC OF UNINITIALIZED MEMORY SIZE
      
      Several string functions have optimizations for constant
      sub-expressions which lead to setting max_length == 0.
      
      For subqueries, where we need a temporary table to holde the result,
      we need to ensure that we use a VARCHAR(0) column rather than a
      CHAR(0) column when such expressions take part in grouping.
      With CHAR(0) end_update() may write garbage into the next field.
------------------------------------------------------------
revno: 6122
committer: vamsikrishna.bhagi@oracle.com
branch nick: mysql-5.6
timestamp: Thu 2014-08-21 19:42:31 +0530
message:
  WL#7717 Expose the SSL library encryption functions to SQL
  
  SQL application developers may benefit from using encryption
  and other cryptographic algorithms available in the
  SSL library. We currently provide SQL functions to a limited
  subset of these (DES and AES symmetric encryption to be
  precise). This worklog is to extend that list through a SQL
  user defined functions plugin.
  
  Algorithms supported: RSA, DSA, DH.
------------------------------------------------------------
revno: 6121 [merge]
committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
branch nick: mysql-5.6
timestamp: Wed 2014-08-20 09:55:19 +0200
message:
  Merge from 5.5. => 5.6  Add my.cnf.d directory for EL7 regular rpm build
    ------------------------------------------------------------
    revno: 2875.468.95 [merge]
    committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
    branch nick: mysql-5.5
    timestamp: Wed 2014-08-20 09:46:38 +0200
    message:
      Add my.cnf.d to regular rpm for EL7 build
        ------------------------------------------------------------
        revno: 2875.472.7
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Tue 2014-08-12 19:37:49 +0200
        message:
          Corrected typo
        ------------------------------------------------------------
        revno: 2875.472.6
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Tue 2014-08-12 18:55:05 +0200
        message:
          Experimental testing
        ------------------------------------------------------------
        revno: 2875.472.5
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Tue 2014-08-12 18:26:46 +0200
        message:
          Experimental testing for patch
        ------------------------------------------------------------
        revno: 2875.472.4
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Tue 2014-08-12 16:53:31 +0200
        message:
          Added my.cnf.d directory, removed mysql-5.5-libmysqlclient-symbols.patch
        ------------------------------------------------------------
        revno: 2875.472.3
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Tue 2014-08-12 14:32:16 +0200
        message:
          Add patch mysql-5.5-libmysqlclient-symbols.patch for el7
------------------------------------------------------------
revno: 6120
committer: bin.x.su@oracle.com
branch nick: mysql-5.6
timestamp: Wed 2014-08-20 09:44:01 +0800
message:
  Bug#19450143 - BUF_READ_PAGE_ASYNC CALLS BUF_READ_PAGE_LOW WITH SYNC=TRUE
  
  We should pass sync=false so that we use the asynchronous aio.
  
  Approved by Sunny over IM.
------------------------------------------------------------
revno: 6119
committer: bin.x.su@oracle.com
branch nick: mysql-5.6
timestamp: Tue 2014-08-19 15:10:06 +0800
message:
  Bug#18477009 - INACCURATE HANDLING OF SRV_ACTIVITY_COUNT
  
  We call srv_active_wake_master_thread() directly and one of the places is
  innobase_commit (and prepare as well). This call not only wakes up the
  master thread but also increments the srv_activity_count which tells
  the page_cleaner that server is not idle. That's no what we expect.
  
  We should call srv_active_wake_master_thread() only after the commitment
  of a write trx, but not read-only trx, or after a rollback. This patch also
  changes some call of srv_active_wake_master_thread() to
  ib_wake_master_thread().
  
  Original patch is provided by Inaam.
  
  rb#5909, approved by Jimmy.
------------------------------------------------------------
revno: 6118
committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
branch nick: Bug17450876_mysql-5.6
timestamp: Tue 2014-08-19 09:57:08 +0530
message:
  Bug#17450876:REPLICATION STOP WITH "ERROR IN XID_LOG_EVENT:
  COMMIT COULD NOT BE COMPLETED"
  
  Problem:
  ========
  When a SQL thread which is waiting for commit lock is killed
  and restarted it causes a transaction to be skipped on slave.
  
  Analysis:
  ========
  when SQL thread is at a state where a DML is waiting for MDL
  commit lock if SQL thread is killed then position are getting
  updated in memory. i.e in the existing design positions are
  flushed before the actual commit because of this rli object
  will have its positions updated but the transaction is yet
  to be committed.  When the SQL thread is restarted it reads
  position from the rli object and hence the last transaction
  gets skipped on slave.
  
  Fix:
  ===
  When SQL thread is killed at a stage where it is waiting for
  commit lock, the commit fails and an error is reported back
  saying "Commit could not be completed and Query execution
  was interrupted".  As part of fix SQL threads positions that
  existed before the commit are persisted and they are
  restored back on error.
  
  Similar symptoms exist in case of MTS as well. In MTS
  "The slave coordinator and worker threads are stopped,
  possibly leaving data in inconsistent state" error is
  reported. In MTS a bitmap is maintained for successful
  commits. This bit map is cleared on error and the old
  positions are retrieved from the checkpoint which points to
  old positions.
------------------------------------------------------------
revno: 6117
committer: Sven Sandberg <sven.sandberg@oracle.com>
branch nick: 5.6
timestamp: Mon 2014-08-18 14:29:06 +0200
message:
  BUG#18385953 - RPL_GTID_STRESS_FAILOVER FAILS WITH "ERROR IN SYNC_WITH_MASTER.INC"
  
  This test failed sporadically in the cleanup code.
  The cleanup code contained this:
  
    for each server:
      DROP DATABASE
      --source include/stop_slave.inc
      CHANGE MASTER TO MASTER_AUTO_POSITION = 0;
      --source include/start_slave.inc
  
  The problem is that CHANGE MASTER will drop the relay logs.  If the IO
  thread was ahead of the SQL thread at this point, received and
  not-yet-executed transactions in the relay log would be lost.  Since it
  does not use the auto-position protocol when it does the
  start_slave.inc, replication would resume after the lost transaction
  rather than retransmit it.
  
  This caused two types of failures:
   1. The IO thread could be stopped in the middle of a transaction, when
      the SQL thread had processed only up to the last complete transaction.
      Here all transactions consist of two events: Gtid followed by Query.
      Thus, the last received transaction was a Gtid and after
      start_slave.inc the slave would receive a Query. The slave SQL thread
      would then see a Query without Gtid. This looks like an anonymous
      transaction, which is not allowed when GTID_MODE = ON. So the SQL thread
      would stop with error 1782: "Error '@@SESSION.GTID_NEXT cannot be set to
      ANONYMOUS when @@GLOBAL.GTID_MODE = ON.' on query. Default database: 
      'db_3'. Query: 'DROP DATABASE db_3'".
   2. The IO thread could be stopped between transactions, when the SQL
      thread had processed only up to the second-last transaction.
      Then the entire transaction would get lost. Later, in rpl_sync.inc,
      the GTID would not be received at all by the slave, so the sync would
      fail with a timeout.
  
  Fixed by dropping the databases and syncing all servers before stopping
  all the slave threads and executing CHANGE MASTER.
------------------------------------------------------------
revno: 6116
committer: Joao Gramacho <joao.gramacho@oracle.com>
branch nick: mysql-5.6
timestamp: Thu 2014-08-14 17:44:55 +0100
message:
  Bug#19311260 ASSERTION IN MTS WHEN WORKER IS KILLED WHILE WAITING FOR
               COMMIT LOCK
  
  Problem:
  =======
  
  With MTS enabled, when a worker is killed while waiting for commit
  lock, it is causing a debug assert to fail.
  
  Analysis:
  ========
  
  When an error is reported through my_error() function call, the assert
  expects 'thd->get_stmt_da()->m_status' diagnostic variable to be
  'DA_EMPTY', but  when a worker reaches 
  Xid_log_event::do_apply_event_worker, thd->get_stmt_da()->m_status has
  'DA_OK' as value.
  
  In STS version of Xid_log_event applier, because of the above
  explained, the THD object needs to be reset so that the errors, flags
  and diagnostic variables that are set by the previous command are
  cleared.
  
  Fix:
  ===
  
  Added code into MTS version of Xid_log_event "do_apply_event_worker" to
  reset THD for the next command the same way it is done for STS version
  "do_apply_event".
------------------------------------------------------------
revno: 6115 [merge]
committer: mithun <mithun.c.y@oracle.com>
branch nick: mysql-5.6
timestamp: Tue 2014-08-12 17:24:15 +0530
message:
  Bug #11755818 : LIKE DOESN'T MATCH WHEN CP932_BIN/SJIS_BIN
                  COLLATIONS ARE USED.
  
  Merge from mysql-5.5
    ------------------------------------------------------------
    revno: 2875.468.94
    committer: mithun <mithun.c.y@oracle.com>
    branch nick: mysql-5.5
    timestamp: Tue 2014-08-12 17:16:51 +0530
    message:
      Bug #11755818 : LIKE DOESN'T MATCH WHEN CP932_BIN/SJIS_BIN
                      COLLATIONS ARE USED.
      
      ISSUE :
      -------
      Code points of HALF WIDTH KATAKANA in SJIS/CP932 range from
      A1 to DF. In function my_wildcmp_mb_bin_impl while comparing
      such single byte code points, there is a code which compares
      signed character with unsigned character. Because of this,
      comparisons of two same code points representing a HALF
      WIDTH KATAKANA character always fails.
      
      Solution:
      ---------
      A code point of HALF WIDTH KATAKANA at-least need 8 bits.
      Promoting the variable from uchar to int will fix the issue.
------------------------------------------------------------
revno: 6114
committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com>
branch nick: mysql-5.6
timestamp: Tue 2014-08-12 14:42:00 +0530
message:
  Bug#19169765 PB2 RPL_GTID_SERVER_SIGHUP.TEST FAILING SPORADICALLY WITH RESULT MISMATCH
  
  Problem: rpl_gtid_server_sighup.test is failing sporadically with result mismatch.
  A rotate event is getting generated in the relay logs sporadically.
  
  Analysis: The test script tests sighup signal (flush logs) behaviour 
  on both master and slave i.e., the test runs in two iteration
  first iteration on master and second iteration on slave. At the end
  of the each iteration, test restarts server to make sure that
  newly generated binary log/relay log does not cause any issues.
  After the first iteration's restart, we must be sure that the IO
  thread has connected again with the master that has just restarted,
  or else the results of the test case may vary.
  
  Fix: A sync with slave is added after end of the first iteration.
------------------------------------------------------------
revno: 6113
committer: Joao Gramacho <joao.gramacho@oracle.com>
branch nick: mysql-5.6
timestamp: Mon 2014-08-11 13:02:10 +0100
message:
  BUG#17326020 ASSERTION ON SLAVE AFTER STOP/START SLAVE
               USING MTS+GTID REPLICATION
  
  Problem:
  =======
  
  When the IO thread reconnects to a master using GTID auto positioning
  while in the middle of a transaction, it will left the partial
  transaction on the relaylog and will fully retrieve the same
  transaction again.
  
  If the slave is configured to use MTS, it will hit an assert "!worker"
  once reaching the ROTATE_LOG_EVENT send by the master in the IO thread
  reconnection.
  
  Analysis:
  ========
  
  Once a slave with MTS reaches the beginning of a group (by an
  GTID_LOG_EVENT or QUERY(BEGIN)), it will expect to feed the same
  worker with events until reaching the end of the transaction. No
  events that should be applied synchronously (by the MTS coordinator
  with all workers waiting for jobs) can be applied while MTS is feeding
  a worker with events. The assertion exists to stop the server execution
  in such situations.
  
  The correct behavior of the slave once knowing that a transaction was
  left in the middle and will not finish (as it will be applied again
  from the beginning later) is to abort this transaction.
  
  STS SQL thread knows how to rollback the incomplete transaction, but
  MTS doesn't know how to do it yet.
  
  Fix:
  ===
  
  The SQL slave will now check if it is going to apply a synchronous
  ROTATE_LOG_EVENT sent by the master during GTID auto negotiation after
  IO thread reconnection.
  
  Before applying this ROTATE_LOG_EVENT, the SQL slave will check also if
  it is in the middle of a group. If it is, it will queue to the current
  worker a QUERY(ROLLBACK) event to make the worker gracefully finish its
  work and, only then, will let the MTS coordinator to apply the
  ROTATE_LOG_EVENT in synchronous mode.
  
  @ sql/rpl_slave.cc
  
  Added code into exec_relay_log_event() to inject a QUERY(ROLLBACK)
  event if necessary to make the current worker gracefully finish its
  job before applying an event that needs synchronous MTS execution.
------------------------------------------------------------
revno: 6112
committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
branch nick: Bug17879675_mysql-5.6
timestamp: Mon 2014-08-11 12:06:08 +0530
message:
  Bug#17879675:SHUTDOWN HANG IF SEMISYNC IS ENABLED AND SLAVE
  ABORT
  
  Problem:
  ========
  Step 1. enable semisync and set a big value for
  rpl_semi_sync_master_timeout.
  
  Step 2. kill io thread of slave, so the threads on master
  will keep on WAITING ACK FROM SLAVE.
  
  Step 3. shutdown the master ---hang
  
  Analysis:
  ========
  On master when semisync is enabled the transaction thread
  will wait for an ack from the slave in a conditional timed
  wait. Since the IO thread is already killed and on master
  a huge timeout value is set transaction thread will continue
  to wait for an ack for a long time. At this time if shutdown
  command is issued dump thread will try to go down. But dump
  thread when goes down it has a check if user has enabled
  rpl_semi_sync_master_wait_no_slave or not. If it is enabled
  dump thread will go down without switching off semi sync.
  Transaction thread will continue to wait for an ack even
  when slave count drops to zero. Because of this shutdown
  also will wait for the transaction thread to go down and
  shutdown hangs.
  
  Fix:
  ===
  At the time of shutdown if dump thread finds that there no
  semi sync slaves that are connected to master it will switch
  off semisync even when rpl_semi_sync_master_wait_no_slave
  is set to on. i.e if shutdown finds no slaves are there to
  provide ack it will not honour
  rpl_semi_sync_master_wait_no_slave and it will switch off
  semisync. The transaction thread when woken up realises the
  semi sync is switched off it will not wait any more for ack
  it will continue and shutdown will be complete. When semi
  sync is forcefully shutdown at the time of waiting for an
  ack a warning is written to error log to convey to users
  that it was forceful shutdown.
  
  There can be a scenario where dump thread is already gone
  and transaction thread still waits for an ack. Hence a
  similar fix is implemented for the waiting transaction
  thread. I.e at the time of shutdown the thread gets a
  wakeup signal and it checks if shutdown is in progress
  if no slaves are connected then it will switch off the
  semi sync.
------------------------------------------------------------
revno: 6111
committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com>
branch nick: mysql-5.6
timestamp: Sat 2014-08-09 07:35:41 +0200
message:
  Bug#19295893 : ASSERT ON SYNC_THREAD_LEVELS_G(ARRAY, SYNC_IBUF_BITMAP IN IBUF_BITMAP_GET_MAP_PA
  
  btr_insert_on_non_leaf_level() might get SYNC_IBUF_BITMAP level page temporally for child temporally mini-transaction.
  So the caller of btr_insert_on_non_leaf_level() should not have any SYNC_IBUF_BITMAP level pages.
  
  But btr_insert_into_right_sibling() might call btr_insert_on_non_leaf_level() after ibuf_update_free_bits_zip().
  ibuf_update_free_bits_zip() uses the parent mini-transaction and has SYNC_IBUF_BITMAP level page until committed the mini-transaction.
  
  ibuf_update_free_bits_zip() should be at the last of btr_insert_into_right_sibling().
  
  This problem is only for compressed table.
  
  Approved by Sunny in rb#6253
------------------------------------------------------------
revno: 6110
committer: Bill Qu <bill.qu@Oracle.com>
branch nick: mysql-5.6
timestamp: Fri 2014-08-08 10:12:49 +0800
message:
  BUG#16741603: MYSQLD SCANS ALL BINARY LOGS ON CRASH RECOVERY
  
  Mysql server iterates backwards through binary logs, looking for
  the last binary log that contains a Previous_gtids_log_event for
  gathering the set of gtid_executed, and iterates forwards through
  binary logs, looking for the first binary log that contains both
  Previous_gtids_log_event and gtid_log_event for gathering the set
  of gtid_purged on crash recovery. Mysql server also iterates
  forwards through binary logs, looking for the first binary log
  that contains both Previous_gtids_log_event and gtid_log_event
  for gathering the set of gtid_purged when purging binary logs.
  This may take very long time if the mysql server has many binary
  logs and almost all of them are out of filesystem cache.
  
  To fix the problem, introduce an option
  'simplified-binlog-gtid-recovery', whose default value is false.
  If the option is enabled, we do this: In the first scan (where
  it iterates over binary logs from the newest to the oldest):
  If the last binary log does not contain any GTID event, do not
  read any more binary logs, and set GTID_EXECUTED = '' and
  GTID_PURGED = ''. Otherwise, initialize GTID_EXECUTED as usual.
  Then, in the second scan (where it iterates from the oldest to
  the newest): If the first binary log does not contain any GTID
  event, do not read any more binary logs, and set GTID_PURGED = ''.
------------------------------------------------------------
revno: 6109
committer: Thirunarayanan B<thirunarayanan.balathandayuth@oracle.com>
branch nick: mysql-5.6
timestamp: Wed 2014-08-06 15:34:47 +0530
message:
  Bug #18734396	INNODB IN-PLACE ALTER FAILURES BLOCK FUTURE ALTERS
  
  Analysis:
  	When an InnoDB in-place ALTER fails, it leaves behind both a
  temporary filename like "#sql-ibtid" where tid represents the table ID of
  the table being altered) in its data dictionary. This makes future in-place
  ALTERs of the same table impossible because the temporary table is named
  only with the table ID.
  
  Solution:
  	This patch is adding more uniqueness to the temporary file name. It
  creates a temporary tablename like
  "#sql-ibtid-inc" where 
           tid = the table ID
           inc = static global number that is initialized to a random
  distributed 32-bit number using ut_time() and ut_crc32().It is then 
  incremented atomically for each temporary file name assigned.
  
  	rb5580 Approved by Kevin, Marko
------------------------------------------------------------
revno: 6108 [merge]
committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
branch nick: mysql-5.6
timestamp: Wed 2014-08-06 11:16:54 +0200
message:
  Merge from 5.5 => 5.6 
  
  - Provide mysql-compat-server dependencies
  - Updated Release version for 5.6.21
    ------------------------------------------------------------
    revno: 2875.468.93 [merge]
    committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
    branch nick: mysql-5.5
    timestamp: Wed 2014-08-06 09:56:37 +0200
    message:
      - Merge from mysql-5.5.39-ol7-release branch
      - Reverted version variable 
        ------------------------------------------------------------
        revno: 2875.472.2
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Mon 2014-08-04 15:56:19 +0200
        message:
          Updated for el7 regular rpms
        ------------------------------------------------------------
        revno: 2875.472.1
        committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
        branch nick: mysql-5.5.39-ol7-release
        timestamp: Thu 2014-07-24 11:37:40 +0200
        message:
          Bug#19223915 Provide mysql-compat-server dependencies
------------------------------------------------------------
revno: 6107 [merge]
committer: bin.x.su@oracle.com
branch nick: mysql-5.6
timestamp: Wed 2014-08-06 09:54:52 +0800
message:
  Remove unstable test case innodb_bug18942294, approved by Jimmy over IM.
    ------------------------------------------------------------
    revno: 2875.468.92
    committer: bin.x.su@oracle.com
    branch nick: mysql-5.5
    timestamp: Wed 2014-08-06 09:51:20 +0800
    message:
      Remove unstable test case innodb_bug18942294, approved by Jimmy over IM.
------------------------------------------------------------
revno: 6106
committer: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
branch nick: mysql-5.6-18710853
timestamp: Sat 2014-08-02 13:21:08 +0530
message:
  BUG#18710853: QUERY CACHE NOT INVALIDATED ON CASCADE DELETE 
                IF DB NAME HAS SPECIAL SYMBOLS 
  
  Analysis      
  --------
  The query cache is not invalidated for a table when the CASCADE
  DELETE/UPDATE referential constraint is specified and the
  database name or table name contains special characters.
        
  InnoDB triggers invalidation of the query cache while performing
  the check for CASCADE DELETE/UPDATE referential constraint. InnoDB
  passes the key in the format of 'dbname\0tablename' to the query cache
  interface where the database name and table name are in the canonical
  format(encoded-format for special characters). The key used by the query
  cache interface is 'dbname\0tablename' in its non-canonical format. 
  The lookup performed for query cache invalidation fails for the condition
  specified above due to the mismatch in the key.
        
  Hence the records fetched with the query cache and without the query
  cache differs.
        
  Fix
  ---
     
  Innodb now passes the key 'dbname\0tablename' in its non-canonical format to 
  the query cache interface. Thus the query cache look up succeeds and the
  query is invalidated.
------------------------------------------------------------
revno: 6105 [merge]
committer: Venkata Sidagam <venkata.sidagam@oracle.com>
branch nick: 5.6
timestamp: Fri 2014-08-01 17:11:15 +0530
message:
  Bug #18415196 MYSQL_UPGRADE DUPLICATE KEY ERROR FOR MYSQL.USER FOR 5.5.35+, 5.6.15+, 5.7.3+ 
  
  Merging from mysql-5.5 to mysql-5.6
    ------------------------------------------------------------
    revno: 2875.468.91
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: 5.5
    timestamp: Fri 2014-08-01 17:09:55 +0530
    message:
      Bug #18415196 MYSQL_UPGRADE DUPLICATE KEY ERROR FOR MYSQL.USER FOR 5.5.35+, 5.6.15+, 5.7.3+
      
      Follow-up patch. Removed unwanted code.
------------------------------------------------------------
revno: 6104 [merge]
committer: Venkata Sidagam <venkata.sidagam@oracle.com>
branch nick: 5.6
timestamp: Fri 2014-08-01 14:22:04 +0530
message:
  Bug #18415196 MYSQL_UPGRADE DUPLICATE KEY ERROR FOR MYSQL.USER FOR 5.5.35+, 5.6.15+, 5.7.3+
  
  Merging from mysql-5.5 to mysql-5.6
    ------------------------------------------------------------
    revno: 2875.468.90
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: 5.5
    timestamp: Fri 2014-08-01 14:18:28 +0530
    message:
      Bug #18415196 MYSQL_UPGRADE DUPLICATE KEY ERROR FOR MYSQL.USER FOR 5.5.35+, 5.6.15+, 5.7.3+
      
      Description: mysql_upgrade fails with below error, 
      when there are duplicate entries(like 'root'@'LOCALHOST'
      and 'root'@'localhost') in mysql.user table.
      ERROR 1062 (23000) at line 1140: Duplicate entry 'localhost-root' for key 'PRIMARY'
      FATAL ERROR: Upgrade failed
      
      Analysis: As part of the bug 12917151 fix we are 
      making all the hostnames as lower case hostnames.
      So, this has been done by mysql_upgrade.
      In case of above mentioned duplicate entries 
      mysql_upgrade tries to change hostname to lowercase.
      Since there is already 'root'@'localhost' exists.
      it is failing with "duplicate entry" error.
      
      Fix: Since its a valid error failure. We are 
      making the error more verbose. So, that user will
      delete the duplicate errors manually.
      Along with existing error we are printing below
      error as well.
      ERROR 1644 (45000) at line 1153: Multiple accounts exist for @user_name, @host_name that differ only in Host lettercase; remove all except one of them
------------------------------------------------------------
revno: 6103
committer: mithun <mithun.c.y@oracle.com>
branch nick: mysql-5.6
timestamp: Fri 2014-08-01 13:56:47 +0530
message:
  Bug #11752369 : MYSQLDUMP SHOULD CONVERT GEOMETRY COLUMNS TO
                  HEX WITH --HEX-BLOB OPTION
  
  ISSUE :
  -------
  If mysqldump is executed with --hex-blob option, all the
  blob type data should be converted to hex value. The
  geometry data are also blob, and their values should be
  dumped in hexadecimal form. But mysqldump dumps geometry
  data in binary form.
  
  Fix :
  -----
  If value being dumped is of geometry type and --hex-blob is
  set then mysqldump will dump such values in hexadecimal form.
------------------------------------------------------------
revno: 6102 [merge]
author: akhil.mohan@oracle.com
committer: Akhil Mohan <akhil.mohan@oracle.com>
branch nick: mysql-5.6
timestamp: Fri 2014-08-01 09:04:12 +0200
message:
  Merge from mysql-5.6.20-release
    ------------------------------------------------------------
    revno: 6048.1.12
    tags: mysql-5.6.20
    committer: Ashish Agarwal<ashish.y.agarwal@oracle.com>
    branch nick: mysql-5.6.20-release
    timestamp: Fri 2014-07-18 21:03:31 +0530
    message:
      WL#7219: Fixing failures in pb2
