------------------------------------------------------------
revno: 3493
tags: clone-mysql-5.1.66-ndb-6.3.50-src-build
committer: Maitrayi Sabaratnam <maitrayi.sabaratnam@oracle.com>
branch nick: mysql-5.1-telco-6.3-bugfix
timestamp: Wed 2012-10-31 10:17:12 +0100
message:
  Bug#14798432 - TIMESLICE DUMPING FRAGMENTION INFO WHEN THERE ARE MANY TABLES.
------------------------------------------------------------
revno: 3492
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-29 18:34:05 +0000
message:
  Bug #14828998 	NDB : SLOW FILESYSTEM CAN CAUSE DIH FILE PAGE EXHAUSTION
  
  Limit number of concurrent table definition updates that DIH can issue.
  This avoids a slow filesystem exerting pressure on DIH File page buffers which
  can lead to a crash if they're exhausted.
  
  Add a testcase showing the crash behaviour using error insert and 
  showing that it fixes the problem.
------------------------------------------------------------
revno: 3491
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 12:08:12 +0200
message:
  Ignore C4090 warnings (Windows)
------------------------------------------------------------
revno: 3490
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 12:07:15 +0200
message:
  Regenerated result
------------------------------------------------------------
revno: 3489 [merge]
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 11:11:12 +0200
message:
  Merged in 5.1.66
    ------------------------------------------------------------
    revno: 2555.936.228
    tags: clone-5.1.66-build
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1
    timestamp: Wed 2012-09-05 17:40:13 +0200
    message:
      Bug#13734987 MEMORY LEAK WITH I_S/SHOW AND VIEWS WITH SUBQUERY
      
      In fill_schema_table_by_open(): free item list before restoring active arena.
    ------------------------------------------------------------
    revno: 2555.936.227
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Mon 2012-09-03 11:33:05 +0530
    message:
      The test case result file must not depend on the page size used.
      So removing the maximum row size from the error message and 
      replacing it with text. 
    ------------------------------------------------------------
    revno: 2555.936.226
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-08-31 15:42:00 +0530
    message:
      Bug #13453036 ERROR CODE 1118: ROW SIZE TOO LARGE - EVEN 
      THOUGH IT IS NOT.
      
      The following error message is misleading because it claims 
      that the BLOB space is not counted.  
      
      "ERROR 1118 (42000): Row size too large. The maximum row size for 
      the used table type, not counting BLOBs, is 8126. You have to 
      change some columns to TEXT or BLOBs"
      
      When the ROW_FORMAT=compact or ROW_FORMAT=REDUNDANT is used,
      the BLOB prefix is stored inline along with the row.  So 
      the above error message is changed as follows depending on
      the row format used:
      
      For ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, the error
      message is as follows:
      
      "ERROR 42000: Row size too large (> 8126). Changing some
      columns to TEXT or BLOB may help. In current row format, 
      BLOB prefix of 0 bytes is stored inline."
      
      For ROW_FORMAT=COMPACT or ROW_FORMAT=REDUNDANT, the error
      message is as follows:
      
      "ERROR 42000: Row size too large (> 8126). Changing some
      columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or 
      ROW_FORMAT=COMPRESSED may help. In current row
      format, BLOB prefix of 768 bytes is stored inline."
      
      rb://1252 approved by Marko Makela
    ------------------------------------------------------------
    revno: 2555.936.225
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-08-31 09:51:27 +0300
    message:
      Add forgotten have_debug.inc to a test.
    ------------------------------------------------------------
    revno: 2555.936.224
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-30 21:53:41 +0300
    message:
      Bug#14554000 CRASH IN PAGE_REC_GET_NTH_CONST(NTH=0) DURING COMPRESSED
      PAGE SPLIT
      
      page_rec_get_nth_const(): Map nth==0 to the page infimum.
      
      btr_compress(adjust=TRUE): Add a debug assertion for nth>0. The cursor
      should never be positioned on the page infimum.
      
      btr_index_page_validate(): Add test instrumentation for checking the
      return values of page_rec_get_nth_const() during CHECK TABLE, and for
      checking that the page directory slot 0 always contains only one
      record, the predefined page infimum record.
      
      page_cur_delete_rec(), page_delete_rec_list_end(): Add debug
      assertions guarding against accessing the page slot 0.
      
      page_copy_rec_list_start(): Clarify a comment about ret_pos==0.
      
      rb:1248 approved by Jimmy Yang
    ------------------------------------------------------------
    revno: 2555.936.223
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-30 21:49:24 +0300
    message:
      Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE()
      
      ha_innodb::records_in_range(): Remove a debug assertion
      that prohibits an open range (full table).
      
      The patch by Jorgen Loland only removed the assertion from the
      built-in InnoDB, not from the InnoDB Plugin.
    ------------------------------------------------------------
    revno: 2555.936.222
    committer: Jorgen Loland <jorgen.loland@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-08-28 14:51:01 +0200
    message:
      Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE()
      
      ha_innobase::records_in_range(): Remove a debug assertion
      that prohibits an open range (full table).
      This assertion catches unnecessary calls to this method, 
      but such calls are not harming correctness.
    ------------------------------------------------------------
    revno: 2555.936.221
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-08-21 10:47:17 +0300
    message:
      Fix regression from Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG
      HEURISTICS FOR COMPRESSED PAGE SIZE
      
      The fix of Bug#12845774 was supposed to skip known-to-fail
      btr_cur_optimistic_insert() calls. There was only one such call, in
      btr_cur_pessimistic_update(). All other callers of
      btr_cur_pessimistic_insert() would release and reacquire the B-tree
      page latch before attempting the pessimistic insert. This would allow
      other threads to restructure the B-tree, allowing (and requiring) the
      insert to succeed as an optimistic (single-page) operation.
      
      Failure to attempt an optimistic insert before a pessimistic one would
      trigger an attempt to split an empty page.
      
      rb:1234 approved by Sunny Bains
    ------------------------------------------------------------
    revno: 2555.936.220
    committer: Mattias Jonsson <mattias.jonsson@oracle.com>
    branch nick: topush-5.1
    timestamp: Mon 2012-08-20 12:39:36 +0200
    message:
      Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY
      
      pre-push fix, removed unused variable.
    ------------------------------------------------------------
    revno: 2555.936.219 [merge]
    committer: Mattias Jonsson <mattias.jonsson@oracle.com>
    branch nick: topush-5.1
    timestamp: Mon 2012-08-20 11:18:17 +0200
    message:
      merge
        ------------------------------------------------------------
        revno: 2555.967.2
        committer: Mattias Jonsson <mattias.jonsson@oracle.com>
        branch nick: b13025132-51
        timestamp: Fri 2012-08-17 14:25:32 +0200
        message:
          Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY
          
          Additional patch to remove the part_id -> ref_buffer offset.
          
          The partitioning id and the associate record buffer can
          be found without having to calculate it.
          
          By initializing it for each used partition, and then reuse
          the key-buffer from the queue, it is not needed to have
          such map.
        ------------------------------------------------------------
        revno: 2555.967.1
        committer: Mattias Jonsson <mattias.jonsson@oracle.com>
        branch nick: b13025132-51
        timestamp: Wed 2012-08-15 14:31:26 +0200
        message:
          Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY
          
          The buffer for the current read row from each partition
          (m_ordered_rec_buffer) used for sorted reads was
          allocated on open and freed when the ha_partition handler
          was closed or destroyed.
          
          For tables with many partitions and big records this could
          take up too much valuable memory.
          
          Solution is to only allocate the memory when it is needed
          and free it when nolonger needed. I.e. allocate it in
          index_init and free it in index_end (and to handle failures
          also free it on reset, close etc.)
          
          Also only allocating needed memory, according to
          partitioning pruning.
          
          Manually tested that it does not use as much memory and
          releases it after queries.
    ------------------------------------------------------------
    revno: 2555.936.218
    committer: Alexander Barkov <alexander.barkov@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-08-17 13:14:04 +0400
    message:
      Backporting Bug 14100466 from 5.6.
    ------------------------------------------------------------
    revno: 2555.936.217
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-16 17:45:39 +0300
    message:
      Bug#12595091 POSSIBLY INVALID ASSERTION IN BTR_CUR_PESSIMISTIC_UPDATE()
      
      Facebook got a case where the page compresses really well so that
      btr_cur_optimistic_update() returns DB_UNDERFLOW, but when a record
      gets updated, the compression rate radically changes so that
      btr_cur_insert_if_possible() can not insert in place despite
      reorganizing/recompressing the page, leading to the assertion failing.
      
      rb:1220 approved by Sunny Bains
    ------------------------------------------------------------
    revno: 2555.936.216
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-16 17:37:52 +0300
    message:
      Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG HEURISTICS FOR
      COMPRESSED PAGE SIZE
      
      This was submitted as MySQL Bug 61456 and a patch provided by
      Facebook. This patch follows the same idea, but instead of adding a
      parameter to btr_cur_pessimistic_insert(), we simply remove the
      btr_cur_optimistic_insert() call there and add it to the only caller
      that needs it.
      
      btr_cur_pessimistic_insert(): Do not try btr_cur_optimistic_insert().
      
      btr_insert_on_non_leaf_level_func(): Invoke btr_cur_optimistic_insert()
      before invoking btr_cur_pessimistic_insert().
      
      btr_cur_pessimistic_update(): Clarify in a comment why it is not
      necessary to invoke btr_cur_optimistic_insert().
      
      btr_root_raise_and_insert(): Assert that the root page is not empty.
      This could happen if a pessimistic insert (involving a split or merge)
      is performed without first attempting an optimistic (intra-page) insert.
      
      rb:1219 approved by Sunny Bains
    ------------------------------------------------------------
    revno: 2555.936.215
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-16 17:31:23 +0300
    message:
      Bug#13523839 ASSERTION FAILURES ON COMPRESSED INNODB TABLES
      
      btr_cur_optimistic_insert(): Remove a bogus assertion. The insert may
      fail after reorganizing the page.
      
      btr_cur_optimistic_update(): Do not attempt to reorganize compressed pages,
      because compression may fail after reorganization.
      
      page_copy_rec_list_start(): Use page_rec_get_nth() to restore to the
      ret_pos, which may also be the page infimum.
      
      rb:1221
    ------------------------------------------------------------
    revno: 2555.936.214
    committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
    branch nick: Bug13596613_user_var
    timestamp: Tue 2012-08-14 14:11:01 +0530
    message:
      Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH
      MASTER-MASTER AND USING SET USE
      
      Problem:
      =======
      In a master-master set-up, a master can show a wrong
      'SHOW SLAVE STATUS' output.
      
      Requirements:
      - master-master
      - log_slave_updates
      
      This is caused when using SET user-variables and then using
      it to perform writes. From then on the master that performed
      the insert will have a SHOW SLAVE STATUS that is wrong and  
      it will never get updated until a write happens on the other
      master. On"Master A" the "exec_master_log_pos" is not
      getting updated.
      
      Analysis:
      ========
      Slave receives a "User_var" event from the master and after
      applying the event, when "log_slave_updates" option is
      enabled the slave tries to write this applied event into
      its own binary log. At the time of writing this event the
      slave should use the "originating server-id". But in the
      above case the sever always logs the  "user var events"
      by using its global server-id. Due to this in a
      "master-master" replication when the event comes back to the
      originating server the "User_var_event" doesn't get skipped.
      "User_var_events" are context based events and they always
      follow with a query event which marks their end of group.
      Due to the above mentioned problem with "User_var_event"
      logging the "User_var_event" never gets skipped where as
      its corresponding "query_event" gets skipped. Hence the
      "User_var" event always waits for the next "query event"
      and the "Exec_master_log_position" does not get updated
      properly.
      
      Fix:
      ===
      `MYSQL_BIN_LOG::write' function is used to write events
      into binary log. Within this function a new object for
      "User_var_log_event" is created and this new object is used
      to write the "User_var" event in the binlog. "User var"
      event is inherited from "Log_event". This "Log_event" has
      different overloaded constructors. When a "THD" object
      is present "Log_event(thd,...)" constructor should be used
      to initialise the objects and in the absence of a valid
      "THD" object "Log_event()" minimal constructor should be
      used. In the above mentioned problem always default minimal
      constructor was used which is incorrect. This minimal
      constructor is replaced with "Log_event(thd,...)".
    ------------------------------------------------------------
    revno: 2555.936.213
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: 5.1
    timestamp: Sat 2012-08-11 15:43:04 +0530
    message:
      Bug #13115401: -SSL-KEY VALUE IS NOT VALIDATED AND IT ALLOWS INSECURE 
                     CONNECTIONS IF SPE
      
      Problem description: -ssl-key value is not validated, you can assign any bogus 
      text to --ssl-key and it is not verified that it exists, and more importantly, 
      it allows the client to connect to mysqld.
      
      Fix: Added proper validations checks for --ssl-key.
      
      Note:
      1) Documentation changes require for 5.1, 5.5, 5.6 and trunk in the sections
         listed below and the details are :
      
       http://dev.mysql.com/doc/refman/5.6/en/ssl-options.html#option_general_ssl
          and
       REQUIRE SSL section of
       http://dev.mysql.com/doc/refman/5.6/en/grant.html
      
      2) Client having with option '--ssl', should able to get ssl connection. This 
      will be implemented as part of separate fix in 5.6 and trunk.
    ------------------------------------------------------------
    revno: 2555.936.212
    committer: Sergey Glukhov <sergey.glukhov@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-09 15:34:52 +0400
    message:
      Bug #14409015 	MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING
      When resolving outer fields, Item_field::fix_outer_fields()
      creates new Item_refs for each execution of a prepared statement, so
      these must be allocated in the runtime memroot. The memroot switching
      before resolving JOIN::having causes these to be allocated in the
      statement root, leaking memory for each PS execution.
    ------------------------------------------------------------
    revno: 2555.936.211 [merge]
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-09 10:48:25 +0300
    message:
      Merge from mysql-5.1 to working copy.
        ------------------------------------------------------------
        revno: 2555.966.1 [merge]
        committer: Sunanda Menon <sunanda.menon@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-08-09 08:50:43 +0200
        message:
          Merge from mysql-5.1.65-release
            ------------------------------------------------------------
            revno: 2555.965.1 [merge]
            tags: mysql-5.1.65
            committer: Bjorn Munch <bjorn.munch@oracle.com>
            branch nick: mysql-5.1.65-release
            timestamp: Thu 2012-07-12 10:00:14 +0200
            message:
              Merge unpushed changes from 5.1.64-release
                ------------------------------------------------------------
                revno: 2555.964.4
                committer: Kent Boortz <kent.boortz@oracle.com>
                branch nick: mysql-5.1.64-release
                timestamp: Tue 2012-06-26 16:30:15 +0200
                message:
                  Solve a linkage problem with "libmysqld" on several Solaris platforms:
                  a multiple definition of 'THD::clear_error()' in (at least)
                  libmysqld.a(lib_sql.o) and libmysqld.a(libfederated_a-ha_federated.o).
                  
                  Patch provided by Ramil Kalimullin.
                ------------------------------------------------------------
                revno: 2555.964.3
                committer: Joerg Bruehe <joerg.bruehe@oracle.com>
                branch nick: mysql-5.1.64-release
                timestamp: Thu 2012-06-21 16:26:50 +0200
                message:
                  Fixing wrong comment syntax (discovered by Kent)
                ------------------------------------------------------------
                revno: 2555.964.2
                committer: Kent Boortz <kent.boortz@oracle.com>
                branch nick: mysql-5.1.64-release
                timestamp: Wed 2012-06-20 13:10:13 +0200
                message:
                  Version for this release build is 5.1.64
                ------------------------------------------------------------
                revno: 2555.964.1 [merge]
                committer: Kent Boortz <kent.boortz@oracle.com>
                branch nick: mysql-5.1.64-release
                timestamp: Wed 2012-06-20 13:06:32 +0200
                message:
                  Merge
    ------------------------------------------------------------
    revno: 2555.936.210
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-08-09 09:55:29 +0300
    message:
      Bug#14399148 INNODB TABLES UNDER LOAD PRODUCE DUPLICATE COPIES OF ROWS
      IN QUERIES
      
      This bug was caused by an incorrect fix of
      Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD
      
      There was nothing wrong with btr_pcur_restore_position(), but with the
      use of it in the table scan during index creation.
      
      rb:1206 approved by Jimmy Yang
    ------------------------------------------------------------
    revno: 2555.936.209
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1-11757312
    timestamp: Wed 2012-08-08 22:15:46 +0530
    message:
      BUG#11757312: MYSQLBINLOG DOES NOT ACCEPT INPUT FROM STDIN
      WHEN STDIN IS A PIPE
                  
      Problem: Mysqlbinlog does not accept the input from STDIN when 
      STDIN is a pipe. This prevents the users from passing the input file
      through a shell pipe.    
      
      Background: The my_seek() function does not check if the file descriptor
      passed to it is regular (seekable) file. The check_header() function in
      mysqlbinlog calls the my_b_seek() unconditionally and it fails when
      the underlying file is a PIPE.  
                  
      Resolution: We resolve this problem by checking if the underlying file
      is a regular file by using my_fstat() before calling my_b_seek(). 
      If the underlying file is not seekable we skip the call to my_b_seek()
      in check_header().
    ------------------------------------------------------------
    revno: 2555.936.208
    committer: Nirbhay Choubey <nirbhay.choubey@oracle.com>
    branch nick: 5.1
    timestamp: Tue 2012-08-07 18:58:19 +0530
    message:
      Bug#13928675 MYSQL CLIENT COPYRIGHT NOTICE MUST
                   SHOW 2012 INSTEAD OF 2011
      
      * Added a new macro to hold the current year :
        COPYRIGHT_NOTICE_CURRENT_YEAR
      * Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro
        to take the initial year as parameter and pick
        current year from the above mentioned macro.
    ------------------------------------------------------------
    revno: 2555.936.207
    committer: Harin Vadodaria<harin.vadodaria@oracle.com>
    branch nick: 51-bug14068244
    timestamp: Tue 2012-08-07 16:23:53 +0530
    message:
      Bug#14068244: INCOMPATIBILITY BETWEEN LIBMYSQLCLIENT/LIBMYSQLCLIENT_R
                    AND LIBCRYPTO
      
      Problem: libmysqlclient_r exports symbols from yaSSL library which
               conflict with openSSL symbols. This issue is related to symbols
               used by CURL library and are defined in taocrypt. Taocrypt has
               dummy implementation of these functions. Due to this when a
               program which uses libcurl library functions is compiled using
               libmysqlclient_r and libcurl, it hits segmentation fault in
               execution phase.
      
      Solution: MySQL should not be exporting such symbols. However, these
                functions are not used by MySQL code at all. So avoid compiling
                them in the first place.
    ------------------------------------------------------------
    revno: 2555.936.206
    committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
    branch nick: mysql-5.1
    timestamp: Sun 2012-08-05 16:29:28 +0530
    message:
      Bug #14099846: EXPORT_SET CRASHES DUE TO OVERALLOCATION OF MEMORY
      
      Backport the fix from 5.6 to 5.1
      Base bug number : 11765562
    ------------------------------------------------------------
    revno: 2555.936.205
    committer: Joerg Bruehe <joerg.bruehe@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-07-31 20:41:46 +0200
    message:
      INSTALL-BINARY placeholder: change invalid URLs (request from Kristofer)
    ------------------------------------------------------------
    revno: 2555.936.204
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1
    timestamp: Fri 2012-07-27 09:13:10 +0200
    message:
      Bug#14111180 HANDLE_FATAL_SIGNAL IN PTR_COMPARE_1 / QUEUE_INSERT
      
      Space available for merging was calculated incorrectly.
    ------------------------------------------------------------
    revno: 2555.936.203
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: mysql-5.1-59107
    timestamp: Fri 2012-07-27 12:05:37 +0530
    message:
      Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE
      
      Fixed the missing of federated/include folder at the time 
      of preparing package distribution, issue happens only in 5.1
    ------------------------------------------------------------
    revno: 2555.936.202
    committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
    branch nick: mysql_5_1
    timestamp: Thu 2012-07-26 23:44:43 +0530
    message:
      BUG#13868860 - LIMIT '5' IS EXECUTED WITHOUT ERROR WHEN '5' 
                     IS PLACE HOLDER AND USE SERVER-SIDE 
      
      Analysis:
      LIMIT always takes nonnegative integer constant values. 
      
      http://dev.mysql.com/doc/refman/5.6/en/select.html
      
      So parsing of value '5' for LIMIT in SELECT fails.
      
      But, within prepared statement, LIMIT parameters can be
      specified using '?' markers. Value for the parameter can
      be supplied while executing the prepared statement.
      
      Passing string values, float or double value for LIMIT
      works well from CLI. Because, while setting the value
      for the parameters from the variable list (added using
      SET), if the value is for parameter LIMIT then its 
      converted to integer value. 
      
      But, when prepared statement is executed from the other
      interfaces as J connectors, or C applications etc.
      The value for the parameters are sent to the server
      with execute command. Each item in log has value and
      the data TYPE. So, While setting parameter value
      from this log, value is set to all the parameters
      with the same data type as passed.
      But here logic to convert value to integer type
      if its for LIMIT parameter is missing.
      Because of this,string '5' is set to LIMIT.
      And the same is logged into the binlog file too. 
      
      Fix:
      When executing prepared statement having parameter for
      CLI it worked fine, as the value set for the parameter
      is converted to integer. And this failed in other 
      interfaces as J connector,C Applications etc as this 
      conversion is missing.
      
      So, as a fix added check while setting value for the
      parameters. If the parameter is for LIMIT value then
      its converted to integer value.
    ------------------------------------------------------------
    revno: 2555.936.201
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: mysql-5.1-59107
    timestamp: Thu 2012-07-26 23:23:04 +0530
    message:
      Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE
      
      Fix for pb2 test failure.
    ------------------------------------------------------------
    revno: 2555.936.200
    committer: Nirbhay Choubey <nirbhay.choubey@oracle.com>
    branch nick: B13741677-5.1
    timestamp: Thu 2012-07-26 21:47:03 +0530
    message:
      Bug#13741677 MYSQL_SECURE_INSTALLATION DOES NOT
                   WORK + SAVES ROOT PASSWORD TO DISK!
      
      The secure installation scripts connect to the
      server by storing the password in a temporary
      option file. Now, if the script gets killed or
      fails for some reason, the removal of the option
      file may not take place.
      
      This patch introduces following enhancements :
      * (.sh) Made sure that cleanup happens at every
        call to 'exit 1'. This is performed implicitly
        by END{} in pl.in.
      * (.pl.in) Added a warning in case unlink fails
        to delete the option/query files.
      * (.sh/.pl.in) Added more signals to the signal
        handler list. SIG# 1, 3, 6, 15
    ------------------------------------------------------------
    revno: 2555.936.199
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1
    timestamp: Thu 2012-07-26 15:05:24 +0200
    message:
      Backport of Bug#14171740 65562: STRING::SHRINK SHOULD BE A NO-OP WHEN ALLOCED=0
    ------------------------------------------------------------
    revno: 2555.936.198
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: mysql-5.1-59107
    timestamp: Thu 2012-07-26 15:09:22 +0530
    message:
      Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE
      
      Problem description:
      Table 't' created with two colums having compound index on both the 
      columns under innodb/myisam engine at remote machine. In the local 
      machine same table is created undet the federated engine.
      A select having where clause with along 'AND' operation gives wrong 
      results on local machine.
      
      Analysis: 
      The given query at federated engine is wrongly transformed by 
      federated::create_where_from_key() function and the same was sent to 
      the remote machine. Hence the local machine is showing wrong results.
      
      Given query "select c1 from t where c1 <= 2 and c2 = 1;"
      Query transformed, after ha_federated::create_where_from_key() function is:
      SELECT `c1`, `c2` FROM `t` WHERE  (`c1` IS NOT NULL ) AND 
      ( (`c1` >= 2)  AND  (`c2` <= 1) ) and the same sent to real_query().
      In the above the '<=' and '=' conditions were transformed to '>=' and 
      '<=' respectively.
      
      ha_federated::create_where_from_key() function behaving as below:
      The key_range is having both the start_key and end_key. The start_key 
      is used to get "(`c1` IS NOT NULL )" part of the where clause, this 
      transformation is correct. The end_key is used to get "( (`c1` >= 2) 
      AND  (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') 
      are changed as wrong conditions('>=' and '<=').
      The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, 
      flag = HA_READ_AFTER_KEY}
      
      The store_length is having value '5'. Based on store_length and length 
      values the condition values is applied in HA_READ_AFTER_KEY switch case.
      The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of 
      the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, 
      here the '>=' is getting added as a condition instead of '<='.
      
      Fix:
      Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all 
      parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in 
      the if condition.
    ------------------------------------------------------------
    revno: 2555.936.197
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-07-25 13:51:39 +0530
    message:
      Bug #13113026 INFORMATION_SCHEMA.INNODB_BUFFER_PAGE_LRUFROM 5.6 BACKPORT
      
      Backporting the WL#5716, "Information schema table for InnoDB 
      buffer pool information". Backporting revisions 2876.244.113, 
      2876.244.102 from mysql-trunk.
      
      rb://1175 approved by Jimmy Yang. 
    ------------------------------------------------------------
    revno: 2555.936.196
    committer: Alexander Barkov <alexander.barkov@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-07-24 09:27:00 +0400
    message:
      Fixing wrong copyright. Index.xml was modified in 2005,
      while the copyright notice still mentioned 2003.
    ------------------------------------------------------------
    revno: 2555.936.195
    committer: Bjorn Munch <bjorn.munch@oracle.com>
    branch nick: imct-51
    timestamp: Thu 2012-07-19 15:55:41 +0200
    message:
      Reverting broken configure/make stuff
    ------------------------------------------------------------
    revno: 2555.936.194
    committer: Bjorn Munch <bjorn.munch@oracle.com>
    branch nick: imct-51
    timestamp: Thu 2012-07-19 12:57:36 +0200
    message:
      Bug #14035452 - MODULARIZE MYSQL_CLIENT_TEST
        Added new minimal client using same framework
        Added internal test using it
        Small changes to top level make/configure/cmake to have it built
    ------------------------------------------------------------
    revno: 2555.936.193
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: mysql-5.1-13955256
    timestamp: Thu 2012-07-19 13:52:34 +0530
    message:
      Bug #12615411 - server side help doesn't work as first statement
      
      Problem description:
      Giving "help 'contents'" in the mysql client as a first statement
      gives error
      
      Analysis:
      In com_server_help() function the "server_cmd" variable was
      initialised with buffer->ptr(). And the "server_cmd" variable is not
      updated since we are passing "'contents'"(with single quote) so the
      buffer->ptr() consists of the previous buffer values and it was sent
      to the mysql_real_query() hence we are getting error.
      
      Fix:
      We are not initialising the "server_cmd" variable and we are updating
      the variable with "server_cmd= cmd_buf" in any of the case i.e with
      single quote or without single quote for the contents.
      As part of error message improvement, added new error message in case
      of "help 'contents'".
    ------------------------------------------------------------
    revno: 2555.936.192
    committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-07-18 14:36:08 +0530
    message:
      Bug#11762052: 54599: BUG IN QUERY PLANNER ON QUERIES WITH
                           "ORDER BY" AND "LIMIT BY" CLAUSE
      
      PROBLEM:
      When a 'limit' clause is specified in a query along with
      group by and order by, optimizer chooses wrong index
      there by examining more number of rows than required.
      However without the 'limit' clause, optimizer chooses
      the right index.
      
      ANALYSIS:
      With respect to the query specified, range optimizer chooses
      the first index as there is a range present ( on 'a'). Optimizer
      then checks for an index which would give records in sorted
      order for the 'group by' clause.
      
      While checking chooses the second index (on 'c,b,a') based on
      the 'limit' specified and the selectivity of
      'quick_condition_rows' (number of rows present in the range)
      in 'test_if_skip_sort_order' function. 
      But, it fails to consider that an order by clause on a
      different column will result in scanning the entire index and 
      hence the estimated number of rows calculated above are 
      wrong (which results in choosing the second index).
      
      FIX:
      Do not enforce the 'limit' clause in the call to
      'test_if_skip_sort_order' if we are creating a temporary
      table. Creation of temporary table indicates that there would be
      more post-processing and hence will need all the rows.
      
      This fix is backported from 5.6. This problem is fixed in 5.6 as   
      part of changes for work log #5558
    ------------------------------------------------------------
    revno: 2555.936.191
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-07-12 16:42:07 +0530
    message:
      Bug #11765218 58157: INNODB LOCKS AN UNMATCHED ROW EVEN THOUGH USING
      RBR AND RC
      
      Description: When scanning and locking rows with < or <=, InnoDB locks
      the next row even though row based binary logging and read committed
      is used.
      
      Solution: In the handler, when the row is identified to fall outside
      of the range (as specified in the query predicates), then request the
      storage engine to unlock the row (if possible). This is done in
      handler::read_range_first() and handler::read_range_next().
    ------------------------------------------------------------
    revno: 2555.936.190
    author: bjorn.munch@oracle.com
    committer: Bjorn Munch <bjorn.munch@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-07-11 15:18:34 +0200
    message:
      Raise version number after cloning 5.1.65
------------------------------------------------------------
revno: 3488 [merge]
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 10:54:46 +0200
message:
  Merged in 5.1.65
    ------------------------------------------------------------
    revno: 2555.936.189
    tags: clone-5.1.65-build
    committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
    branch nick: Bug11762670_5.1
    timestamp: Tue 2012-07-10 18:55:07 +0530
    message:
      follow up patch for test script failure for BUG#11762670
    ------------------------------------------------------------
    revno: 2555.936.188 [merge]
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-07-10 13:51:50 +0300
    message:
      merge from  5.1 repo.
        ------------------------------------------------------------
        revno: 2555.963.6
        committer: Bjorn Munch <bjorn.munch@oracle.com>
        branch nick: break-51
        timestamp: Tue 2012-07-10 11:57:24 +0200
        message:
          mysql_client_fw.c was not included in make dist
    ------------------------------------------------------------
    revno: 2555.936.187 [merge]
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-07-10 13:00:03 +0300
    message:
      merge from  5.1 repo.
        ------------------------------------------------------------
        revno: 2555.963.5
        committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com>
        branch nick: Bug11762670_5.1
        timestamp: Tue 2012-07-10 14:23:17 +0530
        message:
          BUG#11762670:MY_B_WRITE RETURN VALUE IGNORED
          
          Problem:
          =======
          The return value from my_b_write is ignored by: `my_b_write_quoted',
          `my_b_write_bit',`Query_log_event::print_query_header'
          
          Most callers of `my_b_printf' ignore the return value. `log_event.cc' 
          has many calls to it. 
          
          Analysis:
          ========
          `my_b_write' is used to write data into a file. If the write fails it
          sets appropriate error number and error message through my_error()
          function call and sets the IO_CACHE::error == -1.
          `my_b_printf' function is also used to write data into a file, it
          internally invokes my_b_write to do the write operation. Upon
          success it returns number of characters written to file and on error
          it returns -1 and sets the error through my_error() and also sets
          IO_CACHE::error == -1.  Most of the event specific print functions
          for example `Create_file_log_event::print', `Execute_load_log_event::print'
          etc are the ones which make several calls to the above two functions and
          they do not check for the return value after the 'print' call. All the above 
          mentioned abuse cases deal with the client side.
          
          Fix:
          ===
          As part of bug fix a check for IO_CACHE::error == -1 has been added at 
          a very high level after the call to the 'print' function.  There are 
          few more places where the return value of "my_b_write" is ignored
          those are mentioned below.
          
          +++ mysys/mf_iocache2.c    2012-06-04 07:03:15 +0000
          @@ -430,7 +430,8 @@
                     memset(buffz, '0', minimum_width - length2);
                   else
                     memset(buffz, ' ', minimum_width - length2);
          -        my_b_write(info, buffz, minimum_width - length2);
          
          +++ sql/log.cc	2012-06-08 09:04:46 +0000
          @@ -2388,7 +2388,12 @@
               {
                 end= strxmov(buff, "# administrator command: ", NullS);
                 buff_len= (ulong) (end - buff);
          -      my_b_write(&log_file, (uchar*) buff, buff_len);
          
          At these places appropriate return value handlers have been added.
    ------------------------------------------------------------
    revno: 2555.936.186 [merge]
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-07-10 12:48:23 +0300
    message:
      merge from  5.1 repo.
        ------------------------------------------------------------
        revno: 2555.963.4
        committer: Bjorn Munch <bjorn.munch@oracle.com>
        branch nick: break-51
        timestamp: Tue 2012-07-10 10:04:57 +0200
        message:
          mysql_client_test did not build within limbysqld/examples
        ------------------------------------------------------------
        revno: 2555.963.3
        committer: Bjorn Munch <bjorn.munch@oracle.com>
        branch nick: grr-51
        timestamp: Mon 2012-07-09 16:36:50 +0200
        message:
          Fixed compile error in mysql_client_test using gcc
        ------------------------------------------------------------
        revno: 2555.963.2
        committer: Bjorn Munch <bjorn.munch@oracle.com>
        branch nick: rfmct-51
        timestamp: Mon 2012-07-09 15:10:07 +0200
        message:
          Refactor mysql_client_test.c into a framework part and a test part
        ------------------------------------------------------------
        revno: 2555.963.1
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: B13889741-5.1
        timestamp: Thu 2012-07-05 13:41:16 +0300
        message:
          Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ |
          HANDLE_FATAL_SIGNAL IN STRNLEN
          
          Fixed the following bounds checking problems :
          1. in check_if_legal_filename() make sure the null terminated
          string is long enough before accessing the bytes in it.
          Prevents pottential read-past-buffer-end
          2. in my_wc_mb_filename() of the filename charset check
          for the end of the destination buffer before sending single
          byte characters into it.
          Prevents write-past-end-of-buffer (and garbaling stack in
          the cases reported here) errors.
          
          Added test cases.
    ------------------------------------------------------------
    revno: 2555.936.185
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-07-05 14:37:48 +0300
    message:
      Bug#14275000
      
      Fixes for BUG11761686 left a flaw that managed to slip away from testing.
      Only effective filtering branch was actually tested with a regression test
      added to rpl_filter_tables_not_exist.
      The reason of the failure is destuction of too early mem-root-allocated memory 
      at the end of the deferred User-var's do_apply_event().
      
      Fixed with bypassing free_root() in the deferred execution branch.
      Deallocation of created in do_apply_event() items is done by the base code
      through THD::cleanup_after_query() -> free_items() that the parent Query
      can't miss.
    ------------------------------------------------------------
    revno: 2555.936.184
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1_b11762667
    timestamp: Tue 2012-07-03 18:00:21 +0530
    message:
      BUG#11762667:MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT
      
      This is a followup patch for the bug enabling the test
      i_binlog.binlog_mysqlbinlog_file_write.test
      this was disabled in mysql trunk and mysql 5.5 as in the release
      build mysqlbinlog was not debug compiled whereas the mysqld was.
      Since have_debug.inc script checks only for mysqld to be debug
      compiled, the test was not being skipped on release builds.
      
      We resolve this problem by creating a new inc file 
      mysqlbinlog_have_debug.inc which checks exclusively for mysqlbinlog
      to be debug compiled. if not it skips the test.
       
    ------------------------------------------------------------
    revno: 2555.936.183
    committer: Gleb Shchepa <gleb.shchepa@oracle.com>
    branch nick: 5.1
    timestamp: Fri 2012-06-29 18:24:43 +0400
    message:
      minor update to make MSVS happy
    ------------------------------------------------------------
    revno: 2555.936.182
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: B13708485-5.1
    timestamp: Thu 2012-06-28 18:38:55 +0300
    message:
      Bug #13708485:  malformed resultset packet crashes client
      
      Several fixes :
      
      * sql-common/client.c
      Added a validity check of the fields metadata packet sent 
      by the server.
      Now libmysql will check if the length of the data sent by
      the server matches what's expected by the protocol before
      using the data.
      
      * client/mysqltest.cc
      Fixed the error handling code in mysqltest to avoid sending
      new commands when the reading the result set failed (and 
      there are unread data in the pipe).
      
      * sql_common.h + libmysql/libmysql.c + sql-common/client.c
      unpack_fields() now generates a proper error when it fails.
      Added a new argument to this function to support the error 
      generation.
      
      * sql/protocol.cc
      Added a debug trigger to cause the server to send a NULL
      insted of the packet expected by the client for testing 
      purposes.
    ------------------------------------------------------------
    revno: 2555.936.181
    committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
    branch nick: mysql-5.1-test
    timestamp: Fri 2012-06-29 13:25:57 +0200
    message:
      Bug#14238406 NEW COMPILATION WARNINGS WITH GCC 4.7 (-WERROR=NARROWING)
      
      This patch fixes various compilation warnings of the type
      "error: narrowing conversion of 'x' from 'datatype1' to
      'datatype2'
    ------------------------------------------------------------
    revno: 2555.936.180
    committer: Gleb Shchepa <gleb.shchepa@oracle.com>
    branch nick: 5.1
    timestamp: Fri 2012-06-29 12:55:45 +0400
    message:
      Backport of the deprecation warning from WL#6219: "Deprecate and remove YEAR(2) type"
      
      Print the warning(note):
      
       YEAR(x) is deprecated and will be removed in a future release. Please use YEAR(4) instead
      
      on "CREATE TABLE ... YEAR(x)" or "ALTER TABLE MODIFY ... YEAR(x)", where x != 4
    ------------------------------------------------------------
    revno: 2555.936.179 [merge]
    committer: Norvald H. Ryeng <norvald.ryeng@oracle.com>
    branch nick: mysql-5.1-merge
    timestamp: Thu 2012-06-28 14:34:49 +0200
    message:
      Merge.
        ------------------------------------------------------------
        revno: 2555.962.1
        committer: Norvald H. Ryeng <norvald.ryeng@oracle.com>
        branch nick: mysql-5.1-13003736
        timestamp: Mon 2012-06-18 09:20:12 +0200
        message:
          Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES
          
          Problem: Some queries with subqueries and a HAVING clause that
          consists only of a column not in the select or grouping lists causes
          the server to crash.
          
          During parsing, an Item_ref is constructed for the HAVING column. The
          name of the column is resolved when JOIN::prepare calls fix_fields()
          on its having clause. Since the column is not mentioned in the select
          or grouping lists, a ref pointer is not found and a new Item_field is
          created instead. The Item_ref is replaced by the Item_field in the
          tree of HAVING clauses. Since the tree consists only of this item, the
          pointer that is updated is JOIN::having. However,
          st_select_lex::having still points to the Item_ref as the root of the
          tree of HAVING clauses.
          
          The bug is triggered when doing filesort for create_sort_index(). When
          find_all_keys() calls select->cond->walk() it eventually reaches
          Item_subselect::walk() where it continues to walk the having clauses
          from lex->having. This means that it finds the Item_ref instead of the
          new Item_field, and Item_ref::walk() tries to dereference the ref
          pointer, which is still null.
          
          The crash is reproducible only in 5.5, but the problem lies latent in
          5.1 and trunk as well.
          
          Fix: After calling fix_fields on the having clause in JOIN::prepare(),
          set select_lex::having to point to the same item as JOIN::having.
          
          This patch also fixes a bug in 5.1 and 5.5 that is triggered if the
          query is executed as a prepared statement. The Item_field is created
          in the runtime arena when the query is prepared, and the pointer to
          the item is saved by st_select_lex::fix_prepare_information() and
          brought back as a dangling pointer when the query is executed, after
          the runtime arena has been reclaimed.
          
          Fix: Backport fix from trunk that switches to the permanent arena
          before calling Item_ref::fix_fields() in JOIN::prepare().
    ------------------------------------------------------------
    revno: 2555.936.178
    committer: Harin Vadodaria<harin.vadodaria@oracle.com>
    branch nick: 51_bug11753779
    timestamp: Tue 2012-06-19 12:56:40 +0530
    message:
      Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST
                    INC_HOST_ERRORS() IS CALLED.
      
      Description: Reverting patch 3755 for bug#11753779
    ------------------------------------------------------------
    revno: 2555.936.177
    author: kent.boortz@oracle.com
    committer: Kent Boortz <kent.boortz@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-06-15 13:31:27 +0200
    message:
      Raise version number after cloning 5.1.64
------------------------------------------------------------
revno: 3487 [merge]
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 10:20:43 +0200
message:
  Merged in 5.1.64
    ------------------------------------------------------------
    revno: 2555.936.176
    tags: clone-5.1.64-build
    committer: sayantan.dutta@oracle.com
    branch nick: mysql-5.1
    timestamp: Thu 2012-06-14 17:07:49 +0530
    message:
      BUG #13946716: FEDERATED_PLUGIN TEST CASE FAIL ON 64BIT ARCHITECTURES
    ------------------------------------------------------------
    revno: 2555.936.175
    committer: Harin Vadodaria<harin.vadodaria@oracle.com>
    branch nick: 51_bug11753779
    timestamp: Wed 2012-06-13 16:03:58 +0530
    message:
      Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST
                    INC_HOST_ERRORS() IS CALLED.
      
      Issue       : Sequence of calling inc_host_errors()
                    and reset_host_errors() required some
                    changes in order to maintain correct
                    connection error count.
      
      Solution    : Call to reset_host_errors() is shifted
                    to a location after which no calls to
                    inc_host_errors() are made.
    ------------------------------------------------------------
    revno: 2555.936.174 [merge]
    committer: Manish Kumar<manish.4.kumar@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-06-12 12:59:13 +0530
    message:
      BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
      
      Problem
      ========
                  
      Replication breaks in the cases if the event length exceeds 
      the size of master Dump thread's max_allowed_packet.
                    
      The reason why this failure is occuring is because the event length is
      more than the total size of the max_allowed_packet, on addition of the  
      max_event_header length exceeds the max_allowed_packet of the DUMP thread.
      This causes the Dump thread to break replication and throw an error.
                            
      That can happen e.g with row-based replication in Update_rows event.
                  
      Fix
      ====
                
      The problem is fixed in 2 steps:
      
      1.) The Dump thread limit to read event is increased to the upper limit
          i.e. Dump thread reads whatever gets logged in the binary log.
      
      2.) On the slave side we increase the the max_allowed_packet for the
          slave's threads (IO/SQL) by increasing it to 1GB.
      
          This is done using the new server option (slave_max_allowed_packet)
          included, is used to regulate the max_allowed_packet of the  
          slave thread (IO/SQL) by the DBA, and facilitates the sending of
          large packets from the master to the slave.
      
          This causes the large packets to be received by the slave and apply
          it successfully.
        ------------------------------------------------------------
        revno: 2555.961.1
        committer: Manish Kumar<manish.4.kumar@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-05-21 12:57:39 +0530
        message:
          BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
          
          Problem
          ========
                      
          SQL statements close to the size of max_allowed_packet produce binary
          log events larger than max_allowed_packet.
                        
          The reason why this failure is occuring is because the event length is
          more than the total size of the max_allowed_packet + max_event_header
          length. Now since the event length exceeds this size master Dump
          thread is unable to send the packet on to the slave.
                                
          That can happen e.g with row-based replication in Update_rows event.
                      
          Fix
          ====
                    
          The problem was fixed by increasing the max_allowed_packet for the
          slave's threads (IO/SQL) by increasing it to 1GB.
          This is done using the new server option included which is used to
          regulate the max_allowed_packet of the slave thread (IO/SQL).
          This causes the large packets to be received by the slave and apply
          it successfully.
    ------------------------------------------------------------
    revno: 2555.936.173
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1
    timestamp: Tue 2012-06-05 15:53:39 +0200
    message:
      Bug#14051002 VALGRIND: CONDITIONAL JUMP OR MOVE IN RR_CMP / MY_QSORT
      
      Patch for 5.1 and 5.5: fix typo in byte comparison in rr_cmp()
    ------------------------------------------------------------
    revno: 2555.936.172
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-06-01 14:12:57 +0530
    message:
      Bug #13933132: [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED
      WHEN KILLING
      
      Suppose there is a query waiting for a lock.  If the user kills
      this query, then "Got error -1 when reading table" error message
      must not be logged in the server log file.  Since this is a user
      requested interruption, no spurious error message must be logged
      in the server log.  This patch will remove the error message from
      the log.
      
      approved by joh and tatjana
    ------------------------------------------------------------
    revno: 2555.936.171
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-05-31 22:28:18 +0530
    message:
      Fixing the accidental incusion of i_binlog.binlog_suppress_info test. 
      Fix for i_binlog.binlog_mysqlbinlog_file_write failure on pb2 
    ------------------------------------------------------------
    revno: 2555.936.170
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-05-31 14:32:29 +0530
    message:
      Fixed the problem in bzr file-id between 5.1 and 5.5 in i_binlog folder.
    ------------------------------------------------------------
    revno: 2555.936.169
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1_b11762667
    timestamp: Wed 2012-05-30 14:00:29 +0530
    message:
      Fixing i_binlog.binlog_mysqlbinlog_file_write failure. 
    ------------------------------------------------------------
    revno: 2555.936.168
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1_b11762667
    timestamp: Wed 2012-05-30 13:54:15 +0530
    message:
      Fixing the build failure on Windows debug build.
    ------------------------------------------------------------
    revno: 2555.936.167
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1_b11762667
    timestamp: Tue 2012-05-29 12:11:30 +0530
    message:
      Bug#11762667: MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT
      
      Problem: mysqlbinlog exits without any error code in case of
      file write error. It is because of the fact that the calls
      to Log_event::print() method does not return a value and the
      thus any error were being ignored.
      
      Resolution: We resolve this problem by checking for the 
      IO_CACHE::error == -1 after every call to Log_event:: print()
      and terminating the further execution.
    ------------------------------------------------------------
    revno: 2555.936.166
    committer: Inaam Rana <inaam.rana@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-05-24 12:37:03 -0400
    message:
      Bug #14100254 65389: MVCC IS BROKEN WITH IMPLICIT LOCK
      
      rb://1088
      approved by: Marko Makela
      
      This bug was introduced in early stages of plugin. We were not
      checking for an implicit lock on sec index rec for trx_id that is
      stamped on current version of the clust_index in case where the
      clust_index has a previous delete marked version.
    ------------------------------------------------------------
    revno: 2555.936.165
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Mon 2012-05-21 17:25:40 +0530
    message:
      Bug #12752572 61579: REPLICATION FAILURE WHILE
      INNODB_AUTOINC_LOCK_MODE=1 AND USING TRIGGER
      
      When an insert stmt like "insert into t values (1),(2),(3)" is
      executed, the autoincrement values assigned to these three rows are
      expected to be contiguous.  In the given lock mode
      (innodb_autoinc_lock_mode=1), the auto inc lock will be released
      before the end of the statement.  So to make the autoincrement
      contiguous for a given statement, we need to reserve the auto inc
      values at the beginning of the statement.  
      
      Modified the fix based on review comment by Svoj.  
    ------------------------------------------------------------
    revno: 2555.936.164
    committer: Rohit Kalhans <rohit.kalhans@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-05-18 14:44:40 +0530
    message:
      BUG#14005409 - 64624
            
      Problem: After the fix for Bug#12589870, a new field that
      stores the length of db name was added in the buffer that
      stores the query to be executed. Unlike for the plain user
      session, the replication execution did not allocate the
      necessary chunk in Query-event constructor. This caused an
      invalid read while accessing this field.
            
      Solution: We fix this problem by allocating a necessary chunk
      in the buffer created in the Query_log_event::Query_log_event()
      and store the length of database name.
    ------------------------------------------------------------
    revno: 2555.936.163
    committer: Gopal Shankar <gopal.shankar@oracle.com>
    branch nick: thdctxdeadlock-51
    timestamp: Thu 2012-05-17 18:07:59 +0530
    message:
      Bug#12636001 : deadlock from thd_security_context
      
      PROBLEM:
      Threads end-up in deadlock due to locks acquired as described
      below,
      
      con1: Run Query on a table. 
        It is important that this SELECT must back-off while
        trying to open the t1 and enter into wait_for_condition().
        The SELECT then is blocked trying to lock mysys_var->mutex
        which is held by con3. The very significant fact here is
        that mysys_var->current_mutex will still point to LOCK_open,
        even if LOCK_open is no longer held by con1 at this point.
      
      con2: Try dropping table used in con1 or query some table.
        It will hold LOCK_open and be blocked trying to lock
        kernel_mutex held by con4.
      
      con3: Try killing the query run by con1.
        It will hold THD::LOCK_thd_data belonging to con1 while
        trying to lock mysys_var->current_mutex belonging to con1.
        But current_mutex will point to LOCK_open which is held
        by con2.
      
      con4: Get innodb engine status
        It will hold kernel_mutex, trying to lock THD::LOCK_thd_data
        belonging to con1 which is held by con3.
      
      So while technically only con2, con3 and con4 participate in the
      deadlock, con1's mysys_var->current_mutex pointing to LOCK_open
      is a vital component of the deadlock.
      
      CYCLE = (THD::LOCK_thd_data -> LOCK_open ->
               kernel_mutex -> THD::LOCK_thd_data)
      
      FIX:
      LOCK_thd_data has responsibility of protecting,
      1) thd->query, thd->query_length
      2) VIO
      3) thd->mysys_var (used by KILL statement and shutdown)
      4) THD during thread delete.
      
      Among above responsibilities, 1), 2)and (3,4) seems to be three
      independent group of responsibility. If there is different LOCK
      owning responsibility of (3,4), the above mentioned deadlock cycle
      can be avoid. This fix introduces LOCK_thd_kill to handle
      responsibility (3,4), which eliminates the deadlock issue.
      
      Note: The problem is not found in 5.5. Introduction MDL subsystem 
      caused metadata locking responsibility to be moved from TDC/TC to
      MDL subsystem. Due to this, responsibility of LOCK_open is reduced. 
      As the use of LOCK_open is removed in open_table() and 
      mysql_rm_table() the above mentioned CYCLE does not form.
      Revision ID for changes,
      open_table() = dlenev@mysql.com-20100727133458-m3ua9oslnx8fbbvz
      mysql_rm_table() = jon.hauglid@oracle.com-20101116100012-kxep9txz2fxy3nmw
    ------------------------------------------------------------
    revno: 2555.936.162
    committer: Nuno Carvalho <nuno.carvalho@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-05-17 11:41:46 +0100
    message:
      Added combinations file to i_rpl suite.
    ------------------------------------------------------------
    revno: 2555.936.161
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-05-17 10:15:54 +0530
    message:
      Fixing a pb2 test case.  All debug_sync test cases
      must include have_debug_sync.inc.  
    ------------------------------------------------------------
    revno: 2555.936.160
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-05-16 16:36:49 +0530
    message:
      Bug #13943231: ALTER TABLE AFTER DISCARD MAY CRASH THE SERVER
      
      The following scenario crashes our mysql server:
      
      1.  set global innodb_file_per_table=1;
      2.  create table t1(c1 int) engine=innodb;
      3.  alter table t1 discard tablespace;
      4.  alter table t1 add unique index(c1);
      
      Step 4 crashes the server.  This patch introduces a check on discarded
      tablespace to avoid the crash.
      
      rb://1041 approved by Marko Makela
    ------------------------------------------------------------
    revno: 2555.936.159
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: mysql-5.1-13955256
    timestamp: Wed 2012-05-16 16:14:27 +0530
    message:
      Bug #13955256: KEYCACHE CRASHES, CORRUPTIONS/HANGS WITH, 
                     FULLTEXT INDEX AND CONCURRENT DML.
      
      Problem Statement:
      ------------------
      1) Create a table with FT index.
      2) Enable concurrent inserts.
      3) In multiple threads do below operations repeatedly
         a) truncate table
         b) insert into table ....
         c) select ... match .. against .. non-boolean/boolean mode
      
      After some time we could observe two different assert core dumps
      
      Analysis:
      --------
      1)assert core dump at key_read_cache():
      Two select threads operating in-parallel on same key 
      root block.
      1st select thread block->status is set to BLOCK_ERROR 
      because the my_pread() in read_block() is returning '0'. 
      Truncate table made the index file size as 1024 and pread 
      was asked to get the block of count bytes(1024 bytes) 
      from offset of 1024 which it cannot read since its 
      "end of file" and retuning '0' setting 
      "my_errno= HA_ERR_FILE_TOO_SHORT" and the key_file_length, 
      key_root[0] is same i.e. 1024. Since block status has BLOCK_ERROR 
      the 1st select thread enter into the free_block() and will 
      be under wait on conditional mutex by making status as 
      BLOCK_REASSIGNED and goes for wait_on_readers(). Other select 
      thread will also work on the same block and sees the status as 
      BLOCK_ERROR and enters into free_block(), checks for BLOCK_REASSIGNED 
      and asserting the server.
      
      2)assert core dump at key_write_cache():
      One select thread and One insert thread.
      Select thread gets the unlocks the 'keycache->cache_lock', 
      which allows other threads to continue and gets the pread() 
      return value as'0'(please see the explanation above) and 
      tries to get the lock on 'keycache->cache_lock' and waits 
      there for the lock.
      Insert thread requests for the block, block will be assigned 
      from the hash list and makes the page_status as 
      'PAGE_WAIT_TO_BE_READ' and goes for the read_block(), waits 
      in the queue since there are some other threads performing 
      reads on the same block.
      Select thread which was waiting for the 'keycache->cache_lock' 
      mutex in the read_block() will continue after getting the my_pread() 
      value as '0' and sets the block status as BLOCK_ERROR and goes to 
      the free_block() and go to the wait_for_readers().
      Now the insert thread will awake and continues. and checks 
      block->status as not BLOCK_READ and it asserts.  
      
      Fix:
      ---
      In the full text code, multiple readers of index file is not guarded. 
      Hence added below below code in _ft2_search() and walk_and_match().
      
      to lock the key_root I have used below code in _ft2_search()
       if (info->s->concurrent_insert)
          mysql_rwlock_rdlock(&share->key_root_lock[0]);
      
      and to unlock 
       if (info->s->concurrent_insert)
         mysql_rwlock_unlock(&share->key_root_lock[0]);
    ------------------------------------------------------------
    revno: 2555.936.158
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-05-16 11:17:48 +0530
    message:
      Bug #12752572 61579: REPLICATION FAILURE WHILE
      INNODB_AUTOINC_LOCK_MODE=1 AND USING TRIGGER
      
      When an insert stmt like "insert into t values (1),(2),(3)" is
      executed, the autoincrement values assigned to these three rows are
      expected to be contiguous.  In the given lock mode
      (innodb_autoinc_lock_mode=1), the auto inc lock will be released
      before the end of the statement.  So to make the autoincrement
      contiguous for a given statement, we need to reserve the auto inc
      values at the beginning of the statement.  
      
      rb://1074 approved by Alexander Nozdrin
    ------------------------------------------------------------
    revno: 2555.936.157
    committer: Nuno Carvalho <nuno.carvalho@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-05-15 22:06:48 +0100
    message:
      BUG#11754117 - 45670: INTVAR_EVENTS FOR FILTERED-OUT QUERY_LOG_EVENTS ARE EXECUTED
      
      Improved random number filtering verification on
      rpl_filter_tables_not_exist test.
    ------------------------------------------------------------
    revno: 2555.936.156
    committer: Marko M?kel? <marko.makela@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-05-15 15:04:39 +0300
    message:
      Bug#14025221 FOREIGN KEY REFERENCES FREED MEMORY AFTER DROP INDEX
      
      dict_table_replace_index_in_foreign_list(): Replace the dropped index
      also in the foreign key constraints of child tables that are
      referencing this table.
      
      row_ins_check_foreign_constraint(): If the underlying index is
      missing, refuse the operation.
      
      rb:1051 approved by Jimmy Yang
    ------------------------------------------------------------
    revno: 2555.936.155
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: B11761822-5.1
    timestamp: Tue 2012-05-15 13:12:22 +0300
    message:
      Bug #11761822: yassl rejects valid certificate which openssl accepts
          
      Applied the fix that updates yaSSL to 2.2.1 and fixes parsing this 
      particular certificate.
      Added a test case with the certificate itself.
    ------------------------------------------------------------
    revno: 2555.936.154
    committer: Bjorn Munch <bjorn.munch@oracle.com>
    branch nick: int-51
    timestamp: Tue 2012-05-15 09:14:44 +0200
    message:
      Added some extra optional path to test suites
    ------------------------------------------------------------
    revno: 2555.936.153
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-05-10 10:18:31 +0530
    message:
      Bug #14007649 65111: INNODB SOMETIMES FAILS TO UPDATE ROWS INSERTED 
      BY A CONCURRENT TRANSACTIO
      
      The member function QUICK_RANGE_SELECT::init_ror_merged_scan() performs
      a table handler clone. Innodb does not provide a clone operation.  
      The ha_innobase::clone() is not there. The handler::clone() does not 
      take care of the ha_innobase->prebuilt->select_lock_type.  Because of 
      this what happens is that for one index we do a locking read, and 
      for the other index we were doing a non-locking (consistent) read. 
      The patch introduces ha_innobase::clone() member function.  
      It is implemented similar to ha_myisam::clone().  It calls the 
      base class handler::clone() and then does any additional operation 
      required.  I am setting the ha_innobase->prebuilt->select_lock_type 
      correctly. 
      
      rb://1060 approved by Marko
    ------------------------------------------------------------
    revno: 2555.936.152 [merge]
    committer: Sunanda Menon <sunanda.menon@oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-05-08 07:19:14 +0200
    message:
      Merge from mysql-5.1.63-release
    ------------------------------------------------------------
    revno: 2555.936.151
    committer: Venkata Sidagam <venkata.sidagam@oracle.com>
    branch nick: mysql-5.1-bug-45740
    timestamp: Mon 2012-05-07 16:46:44 +0530
    message:
      Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY 
                           CAUSES RESTORE PROBLEM
      Problem Statement:
      ------------------
      mysqldump is not having the dump stmts for general_log and slow_log
      tables. That is because of the fix for Bug#26121. Hence, after 
      dropping the mysql database, and applying the dump by enabling the 
      logging, "'general_log' table not found" errors are logged into the 
      server log file.
      
      Analysis:
      ---------
      As part of the fix for Bug#26121, we skipped the dumping of tables 
      for general_log and slow_log, because the data dump of those tables 
      are taking LOCKS, which is not allowed for log tables.
      
      Fix:
      ----
      We came up with an approach that instead of taking both meta data 
      and data dump information for those tables, take only the meta data 
      dump which doesn't need LOCKS.
      As part of fixing the issue we came up with below algorithm.
      Design before fix:
      1) mysql database is having tables like db, event,... general_log,
         ... slow_log...
      2) Skip general_log and slow_log while preparing the tables list
      3) Take the TL_READ lock on tables which are present in the table 
         list and do 'show create table'.
      4) Release the lock.
      
      Design with the fix:
      1) mysql database is having tables like db, event,... general_log,
         ... slow_log...
      2) Skip general_log and slow_log while preparing the tables list
      3) Explicitly call the 'show create table' for general_log and 
         slow_log
      3) Take the TL_READ lock on tables which are present in the table 
         list and do 'show create table'.
      4) Release the lock.
      
      While taking the meta data dump for general_log and slow_log the 
      "CREATE TABLE" is replaced with "CREATE TABLE IF NOT EXISTS". 
      This is because we skipped "DROP TABLE" for those tables, 
      "DROP TABLE" fails for these tables if logging is enabled. 
      Customer is applying the dump by enabling logging so, if the dump 
      has "DROP TABLE" it will fail. Hence, removed the "DROP TABLE" 
      stmts for those tables.
        
      After the fix we could observe "Table 'mysql.general_log' 
      doesn't exist" errors initially that is because in the customer 
      scenario they are dropping the mysql database by enabling the 
      logging, Hence, those errors are expected. Once we apply the 
      dump which is taken before the "drop database mysql", the errors 
      will not be there.
    ------------------------------------------------------------
    revno: 2555.936.150
    committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com>
    branch nick: mysql-5.1
    timestamp: Fri 2012-04-27 19:38:13 +0900
    message:
      Bug#11758510 (#50723): INNODB CHECK TABLE FATAL SEMAPHORE WAIT TIMEOUT POSSIBLY TOO SHORT FOR BI
      Fixed not to check timeout during the check table.
    ------------------------------------------------------------
    revno: 2555.936.149
    committer: irana <irana@dscczz01.us.oracle.com>
    branch nick: mysql-5.1
    timestamp: Thu 2012-04-26 08:17:14 -0700
    message:
      InnoDB: Adjust error message when a dropped tablespace is accessed.
    ------------------------------------------------------------
    revno: 2555.936.148 [merge]
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: 5.1-bug11754117-45670-insert_id_gets_through
    timestamp: Mon 2012-04-23 12:05:05 +0300
    message:
      merge from 5.1 repo
        ------------------------------------------------------------
        revno: 2555.960.1
        committer: Nuno Carvalho <nuno.carvalho@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2012-04-20 22:25:59 +0100
        message:
          BUG#13979418: SHOW BINLOG EVENTS MAY CRASH THE SERVER
          
          The function mysql_show_binlog_events has a local stack variable
          'LOG_INFO linfo;', which is assigned to thd->current_linfo, however
          this variable goes out of scope and is destroyed before clean
          thd->current_linfo.
          
          The problem is solved by moving 'LOG_INFO linfo;' to function scope.
    ------------------------------------------------------------
    revno: 2555.936.147
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: 5.1-bug11754117-45670-insert_id_gets_through
    timestamp: Mon 2012-04-23 11:51:19 +0300
    message:
      BUG#11754117 
      
      rpl_auto_increment_bug45679.test is refined due to not fixed in 5.1 Bug11749859-39934.
    ------------------------------------------------------------
    revno: 2555.936.146
    committer: Andrei Elkin <andrei.elkin@oracle.com>
    branch nick: 5.1-bug11754117-45670-insert_id_gets_through
    timestamp: Fri 2012-04-20 19:41:20 +0300
    message:
      BUG#11754117 incorrect logging of INSERT into auto-increment 
      BUG#11761686 insert_id event is not filtered.
        
      Two issues are covered.
        
      INSERT into autoincrement field which is not the first part in the composed primary key 
      is unsafe by autoincrement logging design. The case is specific to MyISAM engine
      because Innodb does not allow such table definition.
        
      However no warnings and row-format logging in the MIXED mode was done, and
      that is fixed.
        
      Int-, Rand-, User-var log-events were not filtered along with their parent
      query that made possible them to screw up execution context of the following
      query.
        
      Fixed with deferring their execution until the parent query.
      
      ******
      Bug#11754117 
      
      Post review fixes.
    ------------------------------------------------------------
    revno: 2555.936.145
    committer: Mayank Prasad <mayank.prasad@oracle.com>
    branch nick: show_table
    timestamp: Thu 2012-04-19 14:57:34 +0530
    message:
      BUG#12427262 : 60961: SHOW TABLES VERY SLOW WHEN NOT IN SYSTEM DISK CACHE
      
      Reason:
       This is a regression happened because of changes done in code refactoring 
       in 5.1 from 5.0.
      
      Issue: 
       While doing "Show tables" lex->verbose was being checked to avoid opening
       FRM files to get table type. In case of "Show full table", lex->verbose
       is true to indicate table type is required. In 5.0, this check was
       present which got missing in >=5.5.
      
      Fix:
       Added the required check to avoid opening FRM files unnecessarily in case
       of "Show tables".
    ------------------------------------------------------------
    revno: 2555.936.144
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1
    timestamp: Wed 2012-04-18 14:13:13 +0200
    message:
      new header file must be listed in Makefile.am
    ------------------------------------------------------------
    revno: 2555.936.143
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1
    timestamp: Wed 2012-04-18 13:14:05 +0200
    message:
      Backport 5.5=>5.1 Patch for Bug#13805127: 
      Stored program cache produces wrong result in same THD.
    ------------------------------------------------------------
    revno: 2555.936.142
    committer: Nuno Carvalho <nuno.carvalho@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-04-18 10:08:01 +0100
    message:
      WL#6236: Allow SHOW MASTER LOGS and SHOW BINARY LOGS with REPLICATION CLIENT
      
      Currently SHOW MASTER LOGS and SHOW BINARY LOGS require the SUPER
      privilege. Monitoring tools (such as MEM) often want to check this 
      output - for instance MEM generates the SUM of the sizes of the logs 
      reported here, and puts that in the Replication overview within the MEM
      Dashboard.
      However, because of the SUPER requirement, these tools often have an 
      account that holds open the connection whilst monitoring, and can lock
      out administrators when the server gets overloaded and reaches
      max_connections - there is already another SUPER privileged account
      connected, the "monitor". 
      
      As SHOW MASTER STATUS, and all other replication related statements,
      return with either REPLICATION CLIENT or SUPER privileges, this worklog 
      is to make SHOW MASTER LOGS and SHOW BINARY LOGS be consistent with this
      as well, and allow both of these commands with either SUPER or 
      REPLICATION CLIENT. 
      This allows monitoring tools to not require a SUPER privilege any more,
      so is safer in overloaded situations, as well as being more secure, as 
      lighter privileges can be given to users of such tools or scripts.
    ------------------------------------------------------------
    revno: 2555.936.141
    committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
    branch nick: mysql-5.1
    timestamp: Wed 2012-04-18 11:25:01 +0530
    message:
      Bug#12713907:STRANGE OPTIMIZE & WRONG RESULT UNDER
                         ORDER BY COUNT(*) LIMIT.
      
      PROBLEM:
      With respect to problem in the bug description, we
      exhibit different behaviors for the two tables
      presented, because innodb statistics (rec_per_key
      in this case) are updated for the first table
      and not so for the second one. As a result the
      query plan gets changed in test_if_skip_sort_order
      to use 'index' scan. Hence the difference in the
      explain output. (NOTE: We can reproduce the problem
      with first table by reducing the number of tuples
      and changing the table structure)
      
      The varied output w.r.t the query on the second table
      is because of the result in the query plan change.
      When a query plan is changed to use 'index' scan,
      after the call to test_if_skip_sort_order, we set
      keyread to TRUE immedietly. If for some reason
      we drop this index scan for a filesort later on,
      we fetch only the keys not the entire tuple.
      As a result we would see junk values in the result set.
      
      Following is the code flow:
      
      Call test_if_skip_sort_order
      -Choose an index to give sorted output
      -If this is a covering index, set_keyread to TRUE
      -Set the scan to INDEX scan
      
      Call test_if_skip_sort_order second time
      -Index is not chosen (note that we do not pass the
      actual limit value second time. Hence we do not choose
      index scan second time which in itself is a bug fixed
      in 5.6 with WL#5558)
      -goto filesort
      
      Call filesort
      -Create quick range on a different index
      -Since keyread is set to TRUE, we fetch only the columns of
      the index
      -results in the required columns are not fetched
      
      FIX:
      Remove the call to set_keyread(TRUE) from
      test_if_skip_sort_order. The access function which is
      'join_read_first' or 'join_read_last' calls set_keyread anyways.
    ------------------------------------------------------------
    revno: 2555.936.140
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: mysql-5.1
    timestamp: Tue 2012-04-17 13:25:41 +0300
    message:
      Raise version number after cloning 5.1.63
------------------------------------------------------------
revno: 3486 [merge]
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 09:00:49 +0200
message:
  Merged in 5.1.63
    ------------------------------------------------------------
    revno: 2555.948.37 [merge]
    tags: mysql-5.1.63, clone-5.1.63-build
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Tue 2012-04-10 14:21:57 +0300
    message:
      merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.139
        committer: Venkata Sidagam <venkata.sidagam@oracle.com>
        branch nick: mysql-5.1-59107
        timestamp: Mon 2012-04-09 16:42:41 +0530
        message:
          Bug #11766072 59107: MYSQLSLAP CRASHES IF STARTED WITH NO ARGUMENTS ON WINDOWS
          
          This bug is a duplicate of Bug #31173, which was pushed to the 
          mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of 
          the fix
        ------------------------------------------------------------
        revno: 2555.936.138
        committer: Mayank Prasad <mayank.prasad@oracle.com>
        branch nick: 5.1
        timestamp: Fri 2012-04-06 17:03:13 +0530
        message:
          BUG#13738989 : 62136 : FAILED TO FETCH SELECT RESULT USING EMBEDDED MYSQLD
          
          Background : 
          In mysql-5.1, in a fix for bug#47485, code has been changed for 
          mysql client (libmysql/libmysql.c) but corresponding code was not
          changed for embedded mysql. In that code change, after execution
          of a statement, mysql_stmt_store_result() checks for mysql->state
          to be MYSQL_STATUS_STATEMENT_GET_RESULT, instead of
          MYSQL_STATUS_GET_RESULT (earlier).
          
          Reason:
          In embedded mysql code, after execution, mysql->state was not
          set to MYSQL_STATUS_STATEMENT_GET_RESULT, so it was throwing
          OUT_OF_SYNC error.
          
          Fix:
          Fixed the code in libmysqld/lib_sql.cc to have mysql->state
          to be set to MYSQL_STATUS_STATEMENT_GET_RESULT after execution.
        ------------------------------------------------------------
        revno: 2555.936.137
        committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
        branch nick: mysql_5_1
        timestamp: Wed 2012-03-28 12:05:31 +0530
        message:
          Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVE
          
          Analysis:
          -------------------------------
          According to the Manual
          (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
          "Column, index, stored routine, and event names are not case sensitive on any
          platform, nor are column aliases."
          
          In other words, 'lower_case_table_names' does not affect the behaviour of 
          those identifiers.
          
          On the other hand, trigger names are case sensitive on some platforms,
          and case insensitive on others. 'lower_case_table_names' does not affect
          the behaviour of trigger names either.
          
          The bug was that SHOW statements did case sensitive comparison
          for stored procedure / stored function / event names.
          
          Fix:
          Modified the code so that comparison in case insensitive for routines 
          and events for "SHOW" operation.
          
          As part of this commit, only fixing the test failures due to the actual code fix.
        ------------------------------------------------------------
        revno: 2555.936.136 [merge]
        committer: Sunny Bains <Sunny.Bains@Oracle.Com>
        branch nick: 5.1
        timestamp: Wed 2012-03-28 13:35:44 +1100
        message:
          Merge from mysql-5.0
            ------------------------------------------------------------
            revno: 1810.3999.22
            committer: Sunny Bains <Sunny.Bains@Oracle.Com>
            branch nick: mysql-5.0
            timestamp: Wed 2012-03-28 13:08:25 +1100
            message:
              Bug# 13847885 - PURGING STALLS WHEN PURGE_SYS->N_PAGES_HANDLED OVERFLOWS
              
              Change the type of purge_sys_t::n_pages_handled and purge_sys_t::handle_limit
              to ulonglong from ulint. On a 32 bit system doing ~700 deletes per second the
              counters can overflow in ~3.5 months, if they are 32 bit.
              
              Approved by Jimmy Yang over IM.
        ------------------------------------------------------------
        revno: 2555.936.135
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1
        timestamp: Tue 2012-03-27 14:39:27 +0200
        message:
          Backport of fix for Bug#12763207 - ASSERT IN SUBSELECT::SINGLE_VALUE_TRANSFORMER
        ------------------------------------------------------------
        revno: 2555.936.134
        committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
        branch nick: mysql_5_1
        timestamp: Tue 2012-03-27 12:42:11 +0530
        message:
          Bug#11763507 - 56224: FUNCTION NAME IS CASE-SENSITIVE
          
          Analysis:
          -------------------------------
          According to the Manual
          (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html):
          "Column, index, stored routine, and event names are not case sensitive on any
          platform, nor are column aliases."
          
          In other words, 'lower_case_table_names' does not affect the behaviour of 
          those identifiers.
          
          On the other hand, trigger names are case sensitive on some platforms,
          and case insensitive on others. 'lower_case_table_names' does not affect
          the behaviour of trigger names either.
          
          The bug was that SHOW statements did case sensitive comparison
          for stored procedure / stored function / event names.
          
          Fix:
          Modified the code so that comparison in case insensitive for routines 
          and events for "SHOW" operation.
    ------------------------------------------------------------
    revno: 2555.948.36
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: B13934049-5.1-security
    timestamp: Fri 2012-04-06 12:04:07 +0300
    message:
      Bug #13934049: 64884: LOGINS WITH INCORRECT PASSWORD ARE ALLOWED
      
      Fixed an improper type conversion on return that can make the server accept
      logins with a wrong password.
    ------------------------------------------------------------
    revno: 2555.948.35
    committer: Sergey Glukhov <sergey.glukhov@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Wed 2012-04-04 13:29:45 +0400
    message:
      Bug#11766300 59387: FAILING ASSERTION: CURSOR->POS_STATE == 1997660512 (BTR_PCUR_IS_POSITIONE
      Bug#13639204 64111: CRASH ON SELECT SUBQUERY WITH NON UNIQUE INDEX
      The crash happened due to wrong calculation
      of key length during creation of reference for
      sort order index. The problem is that
      keyuse->used_tables can have OUTER_REF_TABLE_BIT enabled
      but used_tables parameter(create_ref_for_key() func) does
      not have it. So key parts which have OUTER_REF_TABLE_BIT
      are ommited and it could lead to incorrect key length
      calculation(zero key length).
    ------------------------------------------------------------
    revno: 2555.948.34 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Wed 2012-03-21 14:58:27 +0200
    message:
      empty weave merge mysql-5.0-security->mysql-5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.37 [merge]
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: merge-5.0-security
        timestamp: Wed 2012-03-21 14:35:25 +0200
        message:
          weave merge mysql-5.0->mysql-5.0-security
    ------------------------------------------------------------
    revno: 2555.948.33 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Wed 2012-03-21 14:53:09 +0200
    message:
      merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.133 [merge]
        committer: Joerg Bruehe <joerg.bruehe@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2012-03-21 11:18:21 +0100
        message:
          Upmerge an empty merge changeset (backmerge of 5.0.96 into main 5.0),
          solve a conflict in ".bzr-mysql/default.conf".
            ------------------------------------------------------------
            revno: 1810.3999.21 [merge]
            author: karen.langford@oracle.com
            committer: hery.ramilison@oracle.com
            branch nick: mysql-5.0
            timestamp: Tue 2012-03-20 17:30:49 +0100
            message:
              Merge from mysql-5.0.96-release
        ------------------------------------------------------------
        revno: 2555.936.132 [merge]
        author: karen.langford@oracle.com
        committer: hery.ramilison@oracle.com
        branch nick: mysql-5.1
        timestamp: Tue 2012-03-20 17:35:41 +0100
        message:
          Merge from mysql-5.1.62-release
            ------------------------------------------------------------
            revno: 2555.959.3 [merge]
            tags: mysql-5.1.62
            committer: Joerg Bruehe <joerg.bruehe@oracle.com>
            branch nick: clone-5.1
            timestamp: Fri 2012-03-02 13:18:12 +0100
            message:
              Upmerge the yaSSL upgrade (to 2.2.0) from MySQL 5.0 to 5.1.
                ------------------------------------------------------------
                revno: 1810.4005.2
                tags: mysql-5.0.96
                committer: Joerg Bruehe <joerg.bruehe@oracle.com>
                branch nick: clone-5.0
                timestamp: Fri 2012-03-02 13:12:07 +0100
                message:
                  Further upgrade the yaSSL library to version 2.2.0
                  to pick up some new security fixes that are in it.
                  
                  Patch provided by Georgi Kodinov.
            ------------------------------------------------------------
            revno: 2555.959.2
            committer: Karen Langford <karen.langford@oracle.com>
            branch nick: mysql-5.1.62-release
            timestamp: Tue 2012-02-28 17:20:30 +0100
            message:
              AIX builds fail for comments using //
            ------------------------------------------------------------
            revno: 2555.959.1 [merge]
            committer: Joerg Bruehe <joerg.bruehe@oracle.com>
            branch nick: clone-5.1
            timestamp: Tue 2012-02-28 12:44:21 +0100
            message:
              Upmerge the copyright year change, from 5.0 to 5.1.
                ------------------------------------------------------------
                revno: 1810.4005.1
                committer: Joerg Bruehe <joerg.bruehe@oracle.com>
                branch nick: clone-5.0
                timestamp: Tue 2012-02-28 12:42:02 +0100
                message:
                  The current year is 2012, and nobody noticed ...
                  Update the year in the copyright notice, file "README".
        ------------------------------------------------------------
        revno: 2555.936.131
        committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
        branch nick: mysql-5.1-bug11766634
        timestamp: Fri 2012-03-16 12:06:29 +0530
        message:
          Bug #11766634 59783: INNODB DATA GROWS UNEXPECTEDLY WHEN INSERTING, TRUNCATING, INSERTING THE
          
          The test case must insert all the records using a single transaction. Otherwise the test 
          case takes more than 15 minutes and will time out in pb2 and mtr.  
        ------------------------------------------------------------
        revno: 2555.936.130
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-03-15 13:30:17 -0400
        message:
          Bug#13825266 RACE IN LOCK_VALIDATE() WHEN ACCESSING PAGES DIRECTLY
          FROM BUFFER POOL
          
          rb://975
          approved by: Marko Makela
          
          There is a race in lock_validate() where we try to access a page
          without ensuring that the tablespace stays valid during the operation
          i.e.: it is not deleted. This patch tries to fix that by using an
          existing flag (the flag is renamed to make it's name more generic
          in line with it's new use).
        ------------------------------------------------------------
        revno: 2555.936.129
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-03-15 12:38:40 -0400
        message:
          Bug#13851171 STRING OVERFLOW IN INNODB CODE FOUND BY STATIC ANALYSIS
          
          rb://976
          approved by: Marko Makela
          
          Add an assertion to ensure that string overflow is not happening.
          Pointed by Coverity analysis.
        ------------------------------------------------------------
        revno: 2555.936.128
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-03-15 11:53:30 -0400
        message:
          Bug#13537504 VALGRIND: COND. JUMP/MOVE DEPENDS ON UNINITIALISED VALUES
          IN OS_THREAD_EQ
          
          rb://977
          approved by: Marko Makela
          
          rw_lock::writer_thread field contains the thread id of current x-holder
          or wait-x thread. This field is un-initialized at lock creation and is
          written to for the first time when an attempt is made to x-lock.
          
          Current code considers ::writer_thread as valid memory region only when
          the lock is held in x-mode (or there is an x-waiter). This is an
          overkill and it generates valgrind warnings.
          
          The fix is to consider ::writer_thread as valid memory region once it
          has been written to.
          
          Reasoning:
          ==========
          The ::writer_thread can be safely considered valid because:
          
          * We only ever do comparison with current calling threads id.
          * We only ever do comparison when ::recursive flag is set
          * We always unset ::recursive flag in x-unlock
          * Same thread cannot be unlocking and attempting to lock at the same
          time
          * thread_id recycling is not an issue because before an id is recycled
          the thread must leave innodb meaning it must release all locks meaning
          it must unset ::recursive flag.
        ------------------------------------------------------------
        revno: 2555.936.127
        committer: Luis Soares <luis.soares@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-03-12 23:23:40 +0000
        message:
          BUG#12400313
          
          Adding missing sync_slave_with_master to the test case.
        ------------------------------------------------------------
        revno: 2555.936.126 [merge]
        committer: Luis Soares <luis.soares@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-03-12 23:16:44 +0000
        message:
          Automerge merge with latest mysql-5.1.
            ------------------------------------------------------------
            revno: 2555.958.2
            committer: Luis Soares <luis.soares@oracle.com>
            branch nick: mysql-5.1
            timestamp: Mon 2012-03-12 23:15:01 +0000
            message:
              BUG#12400313
              
              Hardening the test case:
                - including a diff_tables at the end.
                - increasing the tolerance on the relay limit size.
        ------------------------------------------------------------
        revno: 2555.936.125 [merge]
        committer: Luis Soares <luis.soares@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-03-12 21:58:00 +0000
        message:
          BUG#12400313
          
          Automerge with mysql-5.1.
            ------------------------------------------------------------
            revno: 2555.958.1
            committer: Luis Soares <luis.soares@oracle.com>
            branch nick: mysql-5.1
            timestamp: Mon 2012-03-12 12:28:27 +0000
            message:
              BUG#12400313 RELAY_LOG_SPACE_LIMIT IS NOT WORKING IN MANY CASES
              BUG#64503: mysql frequently ignores --relay-log-space-limit
              
              When the SQL thread goes to sleep, waiting for more events, it sets
              the flag ignore_log_space_limit to true. This gives the IO thread a
              chance to queue some more events and ultimately the SQL thread will be
              able to purge the log once it is rotated. By then the SQL thread
              resets the ignore_log_space_limit to false. However, between the time
              the SQL thread has set the ignore flag and the time it resets it, the
              IO thread will be queuing events in the relay log, possibly going way
              over the limit.
              
              This patch makes the IO and SQL thread to synchronize when they reach
              the space limit and only ask for one event at a time. Thus the SQL
              thread sets ignore_log_space_limit flag and the IO thread resets it to
              false everytime it processes one more event. In addition, everytime
              the SQL thread processes the next event, and the limit has been
              reached, it checks if the IO thread should rotate. If it should, it
              instructs the IO thread to rotate, giving the SQL thread a chance to
              purge the logs (freeing space). Finally, this patch removes the
              resetting of the ignore_log_space_limit flag from purge_first_log,
              because this is now reset by the IO thread every time it processes the
              next event when the limit has been reached.
              
              If the SQL thread is in a transaction, it cannot purge so, there is no
              point in asking the IO thread to rotate. The only thing it can do is
              to ask for more events until the transaction is over (then it can ask
              the IO to rotate and purge the log right away). Otherwise, there would
              be a deadlock (SQL would not be able to purge and IO thread would not
              be able to queue events so that the SQL would finish the transaction).
        ------------------------------------------------------------
        revno: 2555.936.124
        committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
        branch nick: mysql-5.1-bug11766634
        timestamp: Fri 2012-03-09 11:07:16 +0530
        message:
          Bug #11766634 59783: InnoDB data grows unexpectedly when inserting,
          truncating, inserting the same set of rows. When a table is 
          re-created with the same set of rows, the data file size must
          not grow.  
          
          rb:968
          Approved by Marko. 
        ------------------------------------------------------------
        revno: 2555.936.123
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-03-08 17:10:10 +0200
        message:
          Fix a compiler warning about possibly uninitiaizlied variable.
    ------------------------------------------------------------
    revno: 2555.948.32
    committer: Norvald H. Ryeng <norvald.ryeng@oracle.com>
    branch nick: mysql-5.1-security-13031606
    timestamp: Mon 2012-03-12 08:56:56 +0100
    message:
      Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER
      
      Problem: Grouping results by VALUES(alias for string literal) causes
      the server to crash.
      
      Item_insert_values is not constructed to handle other types of
      arguments than field and reference to field. In this case, the
      argument is an Item_string, and this causes
      Item_insert_values::fix_fields() to crash.
      
      Fix: Issue an error message when the argument to Item_insert_values is
      not a field or a reference to a field.
      
      This is slightly in breach with documentation, which states that
      VALUES should return NULL, but the error message is only issued in
      cases where the server otherwise would crash, so there is no change in
      behavior for queries that already work. Future versions will restrict
      syntax so that using VALUES in this way is illegal.
    ------------------------------------------------------------
    revno: 2555.948.31
    committer: Dmitry Lenev <Dmitry.Lenev@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Sun 2012-03-11 16:05:42 +0400
    message:
      Fixed test case for bug #13105873 "valgrind warning:possible
      crash in foreign key handling on subsequent create table if
      not exists".
      
      Do not leave current database unassigned after the end of
      the test case.
    ------------------------------------------------------------
    revno: 2555.948.30 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Thu 2012-03-08 17:20:03 +0200
    message:
      empty weave merge mysql-5.0-security->mysql-5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.36 [merge]
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: merge-5.0-security
        timestamp: Thu 2012-03-08 17:15:43 +0200
        message:
          empty auto merge of mysql-5.0->mysql-5.0-security
    ------------------------------------------------------------
    revno: 2555.948.29 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Thu 2012-03-08 17:16:53 +0200
    message:
      merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.122
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-03-08 14:56:22 +0200
        message:
          Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD
          
          This bug has been there at least since MySQL 4.0.9. (Before 4.0.9, the
          code probably was even more severely broken.)
          
          btr_pcur_restore_position(): When cursor restoration fails, before
          invoking btr_pcur_store_position() move to the previous or next record
          unless cursor->rel_pos==BTR_PCUR_ON or the record was not a user
          record.
          
          This bug can cause skipped records when btr_pcur_store_position() is
          called on the last record of a page. A symptom would be record count
          mismatch in CHECK TABLE, or failure to find a record to delete-mark or
          update or purge. The following operations should be affected by the
          bug:
          
          * row_search_for_mysql(): SELECT, UPDATE, REPLACE, CHECK TABLE,
            (almost anything else than INSERT)
          
          * foreign key CASCADE operations
          
          * row_merge_read_clustered_index(): index creation (since MySQL 5.1
            InnoDB Plugin)
          
          * multi-threaded purge (after MySQL 5.5): not sure, but it might fail
            to purge some records
          
          Not all callers of btr_pcur_restore_position() should be affected.
          Anything that asserts or checks that restoration succeeds is
          unaffected. For example, cursor restoration on the change buffer tree
          should always succeed, because access is being protected by additional
          latches. Likewise, rollback, or any code accesses data dictionary
          tables while holding dict_sys->mutex should be safe.
          
          rb:967 approved by Jimmy Yang
        ------------------------------------------------------------
        revno: 2555.936.121
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1
        timestamp: Tue 2012-03-06 13:30:30 +0100
        message:
          Bug#11761576 54082: HANDLE_SEGFAULT MAKES USE OF UNSAFE FUNCTIONS
          
          Post-push fixes.
        ------------------------------------------------------------
        revno: 2555.936.120 [merge]
        committer: Mattias Jonsson <mattias.jonsson@oracle.com>
        branch nick: topush-5.1
        timestamp: Wed 2012-02-29 20:51:38 +0100
        message:
          merge into mysql-5.1
            ------------------------------------------------------------
            revno: 2555.957.1
            committer: Mattias Jonsson <mattias.jonsson@oracle.com>
            branch nick: b11761296-5.1_no_qc
            timestamp: Mon 2012-02-20 22:59:11 +0100
            message:
              Bug#11761296: 53775: QUERY ON PARTITIONED TABLE RETURNS CACHED
                                                      RESULT FROM PREVIOUS TRANSACTION
              
              The current Query Cache API is not fully compatible with
              the partitioning engine.
              
              There is no good way to implement support for QC due to:
              1) a static callback for ha_partition would need to have access
              to all partition names and call the underlying callback for each
              [sub]partition with the correct name.
              2) pruning would be impossible, even if one used the ulonglong
              engine_data due to if engine_data is changed, the table is
              invalidated by the QC.
              
              So the only viable solution to avoid incorrect data is to not allow
              caching of queries using partitioned tables.
              
              (There are some extra changes, due to removal of \r as line break)
        ------------------------------------------------------------
        revno: 2555.936.119 [merge]
        committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
        branch nick: mysql-5.1-new
        timestamp: Wed 2012-02-29 14:52:08 +0530
        message:
          Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
          
          Analysis:
          ========================
          sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
          instead of escape character in a string literal then sql_mode can be set to 
          "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
          character like any other. 
          
          SQL_MODE set applies to the current client session. And while creating the stored 
          procedure, MySQL stores the current sql_mode and always executes the stored 
          procedure in sql_mode stored with the Procedure, regardless of the server SQL 
          mode in effect when the routine is invoked.  
          
          In the scenario (for which bug is reported), the routine is created with 
          sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
          is "" (NOT SET) by executing statement "call testp('Axel\'s')".
          Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
          is considered as escape character and column "a" (of table "t1") values are 
          updated with "Axel's". The binary log generated for above update operation is as below,
          
            set sql_mode=XXXXXX (for no_backslash_escapes)
            update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
          
          While logging stored procedure statements, the local variables (params) used in
          statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
          (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
          
          On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
          value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
          is also logged in. So that at slave this sql_mode is set before executing the statements
          of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
          parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
          and parsing reported error for "'" (as we have only one "'" no backslash). 
          
          At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
          But above error reported while writing bin log, "'" (of Axel's) is escaped with
          "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
          while writing NAME_CONST for string variable(param, local variable) in bin log 
          irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
          that logging string parameter does not take into account sql_mode value.
          
          Fix:
          ========================
          So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
          (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
          escape such characters while writing NAME_CONST for string variables in bin 
          log. 
          And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
          represented as ''.
          http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
          ways to include quote characters within a string: )
            ------------------------------------------------------------
            revno: 2555.956.1
            committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
            branch nick: mysql-5.1
            timestamp: Wed 2012-02-29 12:23:15 +0530
            message:
              Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
              
              Analysis:
              ========================
              sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
              instead of escape character in a string literal then sql_mode can be set to 
              "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
              character like any other. 
              
              SQL_MODE set applies to the current client session. And while creating the stored 
              procedure, MySQL stores the current sql_mode and always executes the stored 
              procedure in sql_mode stored with the Procedure, regardless of the server SQL 
              mode in effect when the routine is invoked.  
              
              In the scenario (for which bug is reported), the routine is created with 
              sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
              is "" (NOT SET) by executing statement "call testp('Axel\'s')".
              Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
              is considered as escape character and column "a" (of table "t1") values are 
              updated with "Axel's". The binary log generated for above update operation is as below,
              
                set sql_mode=XXXXXX (for no_backslash_escapes)
                update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');
              
              While logging stored procedure statements, the local variables (params) used in
              statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
              (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)
              
              On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
              value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
              is also logged in. So that at slave this sql_mode is set before executing the statements
              of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
              parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
              and parsing reported error for "'" (as we have only one "'" no backslash). 
              
              At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
              But above error reported while writing bin log, "'" (of Axel's) is escaped with
              "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
              while writing NAME_CONST for string variable(param, local variable) in bin log 
              Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
              that logging string parameter does not take into account sql_mode value.
              
              Fix:
              ========================
              So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
              (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
              escape such characters while writing NAME_CONST for string variables in bin 
              log. 
              And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
              represented as ''.
              http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
              ways to include quote characters within a string: )
        ------------------------------------------------------------
        revno: 2555.936.118
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-02-28 21:41:55 +0200
        message:
          Fix a mistake in the Bug#12861864 fix.
          
          row_drop_table_for_mysql(): Really flag the indexes unavailable before
          starting to drop the table.
        ------------------------------------------------------------
        revno: 2555.936.117
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-02-28 14:00:00 +0200
        message:
          Bug#12861864 RACE CONDITION IN BTR_GET_SIZE() AND DROP INDEX/TABLE/DATABASE
          also filed as Bug#13146269, Bug#13713178
          
          btr_get_size(): Add mtr_t parameter. Require that the caller S-latches
          index->lock. If index->page==FIL_NULL or the index is to be dropped,
          return ULINT_UNDEFINED to indicate that the statistics are
          unavailable.
          
          dict_update_statistics(): If btr_get_size() returns ULINT_UNDEFINED,
          fake the index cardinality statistics.
          
          dict_index_set_page(): Unused function, remove.
          
          row_drop_table_for_mysql(): Before starting to drop the table, mark
          the indexes unavailable in the data dictionary cache while holding
          index->lock X-latch.
          
          ha_innobase::prepare_drop_index(), ha_innobase::final_drop_index():
          When setting index->to_be_dropped, acquire the index->lock X-latch.
          
          rb:960 approved by Jimmy Yang
        ------------------------------------------------------------
        revno: 2555.936.116
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-02-27 23:19:14 +0200
        message:
          Remove a bogus BLOB debug assertion that was added in Bug#13721257 fix.
        ------------------------------------------------------------
        revno: 2555.936.115
        committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2012-02-24 11:53:36 +0530
        message:
          Bug#13012483:EXPLAIN EXTENDED, PREPARED STATEMENT, CRASH IN
          CHECK_SIMPLE_EQUALITY
          
          PROBLEM:
          Crash in "check_simple_equality" when using a subquery with "IN" and
          "ALL" in prepare.
          
          ANALYSIS:
          Crash can be reproduced using a simplified query like this one:
          prepare s from "select 1 from g1 where 1 < all (
                          select @:=(1 in (select 1 from g1)) from g1)";
          
          This bug is currently present only on 5.5.and 5.1. Its fixed as part
          of work log(#1110) in 5.6. We are taking one change to fix this
          in 5.5 and 5.1.
          
          Problem seems to be present because we are trying to evaluate "is_null"
          on an argument which is part of a subquery
          (In Item_is_not_null_test::update_used_tables()).
          But the condition to evaluate is only when we do not have a sub query
          present, which means to say that "with_subselect" is not set.
          With respect to the above query, we create an object of type
          "Item_in_optimizer" which by definition is always associated with a
          subquery. While in 5.6 we set "with_subselect" to true for
          "Item_in_optimizer" object, we do not do the same in 5.5. This results in
          the evaluation for "is_null" resulting in a coredump.
          So, we are now setting "with_subselect" to true for "Item_in_optimizer"
          in 5.1 and 5.5.
        ------------------------------------------------------------
        revno: 2555.936.114
        committer: Vasil Dimov <vasil.dimov@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-02-21 17:57:07 +0200
        message:
          Fix Bug#13639142 64128: INNODB ERROR IN SERVER LOG OF INNODB_BUG34300
          
          Suppress innodb_bug34300 from failing if InnoDB prints:
          
            120221 11:05:03  InnoDB: ERROR: the age of the last checkpoint is 9439048,
            InnoDB: which exceeds the log group capacity 9433498.
          
          by default the log capacity is 2 log files, 5 MB each.
        ------------------------------------------------------------
        revno: 2555.936.113 [merge]
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-02-21 14:14:52 +0200
        message:
          merged and updated the version in mysql-5.1
            ------------------------------------------------------------
            revno: 1810.3999.20
            committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
            branch nick: mysql-5.0
            timestamp: Tue 2012-02-21 14:13:31 +0200
            message:
              bumped up the version of the main tree to match the security tree
        ------------------------------------------------------------
        revno: 2555.936.112
        committer: Tatjana Azundris Nuernberg <tatjana.nuernberg@oracle.com>
        branch nick: 51-13454045
        timestamp: Sun 2012-02-19 03:18:49 +0000
        message:
          BUG 13454045 - 63524: BUG #35396 "ABNORMAL/IMPOSSIBLE/LARGE QUERY_TIME AND LOCK_TIME" HAPPENS A
          
          If a query's end time is before before its start time, the system clock has been turn back
          (daylight savings time etc.). When the system clock is changed, we can't tell for certain a
          given query was actually slow. We did not protect against logging such a query with a bogus
          execution time (resulting from end_time - start_time being negative), and possibly logging it
          even though it did not really take long to run.
          
          We now have a sanity check in place.
    ------------------------------------------------------------
    revno: 2555.948.28
    committer: Ramil Kalimullin <ramil.kalimullin@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Tue 2012-03-06 15:13:56 +0400
    message:
      BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN 
      GEOMETRY FUNCTION ARGUMENTS
      
      Fixed --ps-protocol gis test failure.
    ------------------------------------------------------------
    revno: 2555.948.27
    committer: Ramil Kalimullin <ramil.kalimullin@oracle.com>
    branch nick: b12537203-5.1-security
    timestamp: Mon 2012-03-05 22:15:23 +0400
    message:
      BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
      
      A defect in the subquery substitution code may lead to a server crash:
      setting substitution's name should be followed by setting its length
      (to keep them in sync).
    ------------------------------------------------------------
    revno: 2555.948.26
    committer: Ramil Kalimullin <ramil.kalimullin@oracle.com>
    branch nick: b12414917-5.1-security
    timestamp: Mon 2012-03-05 21:58:07 +0400
    message:
      Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS 
      
      Problem:      
      lack of incoming geometry data validation may 
      lead to a server crash when ISCLOSED() function called.
      
      Solution:
      necessary incoming data check added.
    ------------------------------------------------------------
    revno: 2555.948.25
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1-security-bug13635833
    timestamp: Thu 2012-03-01 15:44:23 +0530
    message:
      The innodb plugin module cannot use DEBUG_SYNC_C facility on Windows. 
      Taking care of it.  
    ------------------------------------------------------------
    revno: 2555.948.24
    committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
    branch nick: mysql-5.1-security-bug13635833
    timestamp: Thu 2012-03-01 11:05:51 +0530
    message:
      Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
            
      There are two threads.  In one thread, dml operation is going on 
      involving cascaded update operation.  In another thread, alter 
      table add foreign key constraint is happening.  Under these 
      circumstances, it is possible for the dml thread to access a 
      dict_foreign_t object that has been freed by the ddl thread.  
      The debug sync test case provides the sequence of operations.  
      Without fix, the test case will crash the server (because of 
      newly added assert).  With fix, the alter table stmt will return 
      an error message.  
            
      Backporting the fix from MySQL 5.5 to 5.1
      
      rb:961
      rb:947
    ------------------------------------------------------------
    revno: 2555.948.23 [merge]
    committer: Tatjana Azundris Nuernberg <tatjana.nuernberg@oracle.com>
    branch nick: 51-13431369pb
    timestamp: Wed 2012-02-22 16:18:12 +0100
    message:
      auto-merge
        ------------------------------------------------------------
        revno: 2555.955.1 [merge]
        committer: Tatjana Azundris Nuernberg <tatjana.nuernberg@oracle.com>
        branch nick: 51-13431369
        timestamp: Sun 2012-02-19 08:57:11 +0000
        message:
          BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS
          
          On shutdown(), Windows can drop traffic still queued for sending even if that
          wasn't specifically requested. As a result, fatal errors (those after
          signaling which the server will drop the connection) were sometimes only
          seen as "connection lost" on the client side, because the server-side
          shutdown() erraneously discarded the correct error message before sending
          it.
          
          If on Windows, we now use the Windows API to access the (non-broken) equivalent
          of shutdown().
          
          Backport from trunk
            ------------------------------------------------------------
            revno: 2555.954.1
            committer: Tatjana Azundris Nuernberg <tatjana.nuernberg@oracle.com>
            branch nick: mysql-5.1-security
            timestamp: Fri 2012-02-17 19:02:17 +0000
            message:
              BUG#13431369 - MAIN.VARIABLES-NOTEMBEDDED CRASHES THE SERVER SPORADICALLY ON WINDOWS
              
              On shutdown(), Windows can drop traffic still queued for sending even if that
              wasn't specifically requested. As a result, fatal errors (those after
              signaling which the server will drop the connection) were sometimes only
              seen as "connection lost" on the client side, because the server-side
              shutdown() erraneously discarded the correct error message before sending
              it.
              
              If on Windows, we now use the Windows API to access the (non-broken) equivalent
              of shutdown().
              
              Backport from trunk
    ------------------------------------------------------------
    revno: 2555.948.22
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1-security
    timestamp: Wed 2012-02-22 11:17:50 +0100
    message:
      Bug#13519724 63793: CRASH IN DTCOLLATION::SET(DTCOLLATION &SET)
      
      Backport of fix for:
      Bug#53236 Segfault in DTCollation::set(DTCollation&)
    ------------------------------------------------------------
    revno: 2555.948.21 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Tue 2012-02-21 11:06:08 +0200
    message:
      merge 5.0-security->5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.35
        committer: Sunanda Menon <sunanda.menon@oracle.com>
        branch nick: mysql-5.0-security
        timestamp: Mon 2012-02-20 06:19:12 +0100
        message:
          Raise version number after cloning 5.0.96
    ------------------------------------------------------------
    revno: 2555.948.20
    committer: Karen Langford <karen.langford@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Mon 2012-02-20 17:03:24 +0100
    message:
      Raise version number after cloning 5.1.62
------------------------------------------------------------
revno: 3485 [merge]
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-10-22 08:37:47 +0200
message:
  Merged in 5.1.62
    ------------------------------------------------------------
    revno: 2555.948.19 [merge]
    tags: clone-5.1.62-build
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Sat 2012-02-18 10:58:19 +0200
    message:
      merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.111
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2012-02-17 11:42:04 +0200
        message:
          Bug#13721257 RACE CONDITION IN UPDATES OR INSERTS OF WIDE RECORDS
          
          This bug was originally filed and fixed as Bug#12612184. The original
          fix was buggy, and it was patched by Bug#12704861. Also that patch was
          buggy (potentially breaking crash recovery), and both fixes were
          reverted.
          
          This fix was not ported to the built-in InnoDB of MySQL 5.1, because
          the function signatures of many core functions are different from
          InnoDB Plugin and later versions. The block allocation routines and
          their callers would have to changed so that they handle block
          descriptors instead of page frames.
          
          When a record is updated so that its size grows, non-updated columns
          can be selected for external (off-page) storage. The bug is that the
          initially inserted updated record contains an all-zero BLOB pointer to
          the field that was not updated. Only after the BLOB pages have been
          allocated and written, the valid pointer can be written to the record.
          
          Between the release of the page latch in mtr_commit(mtr) after
          btr_cur_pessimistic_update() and the re-latching of the page in
          btr_pcur_restore_position(), other threads can see the invalid BLOB
          pointer consisting of 20 zero bytes. Moreover, if the system crashes
          at this point, the situation could persist after crash recovery, and
          the contents of the non-updated column would be permanently lost.
          
          The problem is amplified by the ROW_FORMAT=DYNAMIC and
          ROW_FORMAT=COMPRESSED that were introduced in
          innodb_file_format=barracuda in InnoDB Plugin, but the bug does exist
          in all InnoDB versions.
          
          The fix is as follows. After a pessimistic B-tree operation that needs
          to write out off-page columns, allocate the pages for these columns in
          the mini-transaction that performed the B-tree operation (btr_mtr),
          but write the pages in a separate mini-transaction (blob_mtr). Do
          mtr_commit(blob_mtr) before mtr_commit(btr_mtr). A quirk: Do not reuse
          pages that were previously freed in btr_mtr. Only write the off-page
          columns to 'fresh' pages.
          
          In this way, crash recovery will see redo log entries for blob_mtr
          before any redo log entry for btr_mtr. It will apply the BLOB page
          writes to pages that were marked free at that point. If crash recovery
          fails to see all of the btr_mtr redo log, there will be some
          unreachable BLOB data in free pages, but the B-tree will be in a
          consistent state.
          
          btr_page_alloc_low(): Renamed from btr_page_alloc(). Add the parameter
          init_mtr. Return an allocated block, or NULL. If init_mtr!=mtr but
          the page was already X-latched in mtr, do not initialize the page.
          
          btr_page_alloc(): Wrapper for btr_page_alloc_for_ibuf() and
          btr_page_alloc_low().
          
          btr_page_free(): Add a debug assertion that the page was a B-tree page.
          
          btr_lift_page_up(): Return the father block.
          
          btr_compress(), btr_cur_compress_if_useful(): Add the parameter ibool
          adjust, for adjusting the cursor position.
          
          btr_cur_pessimistic_update(): Preserve the cursor position when
          big_rec will be written and the new flag BTR_KEEP_POS_FLAG is defined.
          Remove a duplicate rec_get_offsets() call. Keep the X-latch on
          index->lock when big_rec is needed.
          
          btr_store_big_rec_extern_fields(): Replace update_inplace with
          an operation code, and local_mtr with btr_mtr. When not doing a
          fresh insert and btr_mtr has freed pages, put aside any pages that
          were previously X-latched in btr_mtr, and free the pages after
          writing out all data. The data must be written to 'fresh' pages,
          because btr_mtr will be committed and written to the redo log after
          the BLOB writes have been written to the redo log.
          
          btr_blob_op_is_update(): Check if an operation passed to
          btr_store_big_rec_extern_fields() is an update or insert-by-update.
          
          fseg_alloc_free_page_low(), fsp_alloc_free_page(),
          fseg_alloc_free_extent(), fseg_alloc_free_page_general(): Add the
          parameter init_mtr. Return an allocated block, or NULL. If
          init_mtr!=mtr but the page was already X-latched in mtr, do not
          initialize the page.
          
          xdes_get_descriptor_with_space_hdr(): Assert that the file space
          header is being X-latched.
          
          fsp_alloc_from_free_frag(): Refactored from fsp_alloc_free_page().
          
          fsp_page_create(): New function, for allocating, X-latching and
          potentially initializing a page. If init_mtr!=mtr but the page was
          already X-latched in mtr, do not initialize the page.
          
          fsp_free_page(): Add ut_ad(0) to the error outcomes.
          
          fsp_free_page(), fseg_free_page_low(): Increment mtr->n_freed_pages.
          
          fsp_alloc_seg_inode_page(), fseg_create_general(): Assert that the
          page was not previously X-latched in the mini-transaction. A file
          segment or inode page should never be allocated in the middle of an
          mini-transaction that frees pages, such as btr_cur_pessimistic_delete().
          
          fseg_alloc_free_page_low(): If the hinted page was allocated, skip the
          check if the tablespace should be extended. Return NULL instead of
          FIL_NULL on failure. Remove the flag frag_page_allocated. Instead,
          return directly, because the page would already have been initialized.
          
          fseg_find_free_frag_page_slot() would return ULINT_UNDEFINED on error,
          not FIL_NULL. Correct a bogus assertion.
          
          fseg_alloc_free_page(): Redefine as a wrapper macro around
          fseg_alloc_free_page_general().
          
          buf_block_buf_fix_inc(): Move the definition from the buf0buf.ic to
          buf0buf.h, so that it can be called from other modules.
          
          mtr_t: Add n_freed_pages (number of pages that have been freed).
          
          page_rec_get_nth_const(), page_rec_get_nth(): The inverse function of
          page_rec_get_n_recs_before(), get the nth record of the record
          list. This is faster than iterating the linked list. Refactored from
          page_get_middle_rec().
          
          trx_undo_rec_copy(): Add a debug assertion for the length.
          
          trx_undo_add_page(): Return a block descriptor or NULL instead of a
          page number or FIL_NULL.
          
          trx_undo_report_row_operation(): Add debug assertions.
          
          trx_sys_create_doublewrite_buf(): Assert that each page was not
          previously X-latched.
          
          page_cur_insert_rec_zip_reorg(): Make use of page_rec_get_nth().
          
          row_ins_clust_index_entry_by_modify(): Pass BTR_KEEP_POS_FLAG, so that
          the repositioning of the cursor can be avoided.
          
          row_ins_index_entry_low(): Add DEBUG_SYNC points before and after
          writing off-page columns. If inserting by updating a delete-marked
          record, do not reposition the cursor or commit the mini-transaction
          before writing the off-page columns.
          
          row_build(): Tighten a debug assertion about null BLOB pointers.
          
          row_upd_clust_rec(): Add DEBUG_SYNC points before and after writing
          off-page columns. Do not reposition the cursor or commit the
          mini-transaction before writing the off-page columns.
          
          rb:939 approved by Jimmy Yang
    ------------------------------------------------------------
    revno: 2555.948.18 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Fri 2012-02-17 11:55:06 +0200
    message:
      merge mysql-5.0-security->mysql-5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.34 [merge]
        tags: clone-5.0.96-build
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: merge-5.0-security
        timestamp: Fri 2012-02-17 11:51:14 +0200
        message:
          merged mysql-5.0->mysql-5.0-security
    ------------------------------------------------------------
    revno: 2555.948.17 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Fri 2012-02-17 11:52:41 +0200
    message:
      merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.110
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-16 15:54:16 +0200
        message:
          Fix link error on Windows.
          error LNK2001: unresolved external symbol _debug_sync_C_callback_ptr
        ------------------------------------------------------------
        revno: 2555.936.109 [merge]
        committer: Kent Boortz <kent.boortz@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-16 12:02:53 +0100
        message:
          Merge
            ------------------------------------------------------------
            revno: 2555.953.4
            committer: Marko M?kel? <marko.makela@oracle.com>
            branch nick: mysql-5.1
            timestamp: Thu 2012-02-16 12:24:11 +0200
            message:
              Add instrumentation for Bug#13721257 RACE CONDITION IN UPDATES OR INSERTS
              OF WIDE RECORDS
              
              row_ins_index_entry_low(), row_upd_clust_rec(): Make a redo log
              checkpoint if a DEBUG flag is set. Add DEBUG_SYNC around
              btr_store_big_rec_extern_fields().
              
              rb:946 approved by Jimmy Yang
            ------------------------------------------------------------
            revno: 2555.953.3
            committer: Marko M?kel? <marko.makela@oracle.com>
            branch nick: mysql-5.1
            timestamp: Thu 2012-02-16 12:20:41 +0200
            message:
              Correct a few copyright messages.
        ------------------------------------------------------------
        revno: 2555.936.108
        committer: MySQL Build Team<mysql-build@oss.oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-16 11:35:30 +0100
        message:
          Updated/added copyright headers
        ------------------------------------------------------------
        revno: 2555.936.107 [merge]
        committer: Kent Boortz <kent.boortz@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-16 11:17:04 +0100
        message:
          Merge
            ------------------------------------------------------------
            revno: 2555.953.2
            committer: Marko M?kel? <marko.makela@oracle.com>
            branch nick: mysql-5.1
            timestamp: Wed 2012-02-15 16:28:00 +0200
            message:
              Remove a race condition in innodb_bug53756.test.
              Before killing the server, tell mysql-test-run that it is to be expected.
              
              Discussed with Bjorn Munch on IM.
            ------------------------------------------------------------
            revno: 2555.953.1
            committer: Marko M?kel? <marko.makela@oracle.com>
            branch nick: mysql-5.1
            timestamp: Wed 2012-02-15 15:53:29 +0200
            message:
              store_create_info(): Fix a compiler warning about unused variable.
        ------------------------------------------------------------
        revno: 2555.936.106 [merge]
        committer: Kent Boortz <kent.boortz@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2012-02-15 17:21:38 +0100
        message:
          Updated/added copyright headers
            ------------------------------------------------------------
            revno: 1810.3999.19
            committer: MySQL Build Team<mysql-build@oss.oracle.com>
            branch nick: mysql-5.0
            timestamp: Wed 2012-02-15 17:13:47 +0100
            message:
              Updated/added copyright headers
        ------------------------------------------------------------
        revno: 2555.936.105
        committer: Sunny Bains <Sunny.Bains@Oracle.Com>
        branch nick: 5.1
        timestamp: Fri 2012-02-10 14:09:12 +1100
        message:
          BUG#12739098 - 62401: ASSERTION TRX->ERROR_STATE == DB_SUCCESS, QUE0QUE.C LINE 1264 ON TRUNCATE 
                      
          During FIC error handling the trx->error_state was not being set to DB_SUCCESS
          after failure, before attempting the next DDL SQL operation. This reset to
          DB_SUCCESS is somewhat of a requirement though not explicitly stated anywhere.
          The fix is to reset it to DB_SUCCESS in row0merge.cc if row_merge_rename_indexes
          or row_merge_drop_index functions fail, also reset to DB_SUCCESS at trx commit.
          				          
          rb://935 Approved by Jimmy Yang.
    ------------------------------------------------------------
    revno: 2555.948.16 [merge]
    committer: Joerg Bruehe <joerg.bruehe@oracle.com>
    branch nick: security-5.1
    timestamp: Thu 2012-02-16 15:55:53 +0100
    message:
      Merge compile fix for AIX into delivery tree.
        ------------------------------------------------------------
        revno: 2555.952.1
        committer: Joerg Bruehe <joerg.bruehe@oracle.com>
        branch nick: bzero-5.1
        timestamp: Thu 2012-01-19 17:05:47 +0100
        message:
          Compile fix needed for AIX,
          to work around the lack of a bzero() prototype.
    ------------------------------------------------------------
    revno: 2555.948.15 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: B13706828-5.1-security
    timestamp: Mon 2012-02-13 13:40:12 +0200
    message:
      merge from 5.0-security
        ------------------------------------------------------------
        revno: 1810.4002.33
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: B13706828-5.0-security
        timestamp: Fri 2012-02-10 16:33:27 +0200
        message:
          Bug #13706828: UPGRADE YASSL FROM 1.7.2 TO 2.1.4
          
          $SUBJ$
          1. Took a diff between the previous base version and the
          mysql sources.
          2. Added the new 2.1.4 base version.
          3. Reviewed and re-applied the diff from step #1.
    ------------------------------------------------------------
    revno: 2555.948.14 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: upgrade-yassl-5.1-security
    timestamp: Fri 2012-02-10 11:49:48 +0200
    message:
      merge
        ------------------------------------------------------------
        revno: 2555.951.1
        committer: Martin Hansson <martin.hansson@oracle.com>
        branch nick: mysql-5.1-security
        timestamp: Tue 2012-02-07 14:16:09 +0100
        message:
          Bug #11765810 58813: SERVER THREAD HANGS WHEN JOIN + WHERE + GROUP BY
          IS EXECUTED TWICE FROM P
          
          This bug is a duplicate of bug 12567331, which was pushed to the
          optimizer backporting tree on 2011-06-11. This is just a back-port of
          the fix. Both test cases are included as they differ somewhat.
    ------------------------------------------------------------
    revno: 2555.948.13 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: upgrade-yassl-5.1-security
    timestamp: Fri 2012-02-10 11:39:51 +0200
    message:
      empty merge of mysql-5.0-security->mysql-5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.32
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: upgrade-yassl-5.0-security
        timestamp: Fri 2012-02-10 11:10:07 +0200
        message:
          Bug#13706621 :  UNIFY THE YASSL VERSIONS THAT WE USE BY BACKPORTING 5.1 
          AND 5.5 YASSL FIXES.
          
          Took the 5.5 yassl code and applied it to the 5.0 codebase, keeping the
          compilation files.
    ------------------------------------------------------------
    revno: 2555.948.12
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: upgrade-yassl-5.1-security
    timestamp: Fri 2012-02-10 11:35:36 +0200
    message:
      Bug#13706621 :  UNIFY THE YASSL VERSIONS THAT WE USE BY BACKPORTING 5.1 
      AND 5.5 YASSL FIXES.
      
      Took the 5.5 yassl directory and moved it to the 5.1 tree, while
      preserving the makefiles.
    ------------------------------------------------------------
    revno: 2555.948.11 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Mon 2012-02-06 18:26:48 +0200
    message:
      empty weave merge mysql-5.0-security->mysql-5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.31 [merge]
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: merge-5.0-security
        timestamp: Mon 2012-02-06 18:23:41 +0200
        message:
          merged mysql-5.0->mysql-5.0-security
    ------------------------------------------------------------
    revno: 2555.948.10 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Mon 2012-02-06 18:24:51 +0200
    message:
      merged mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.104
        committer: Vasil Dimov <vasil.dimov@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-02-06 12:44:59 +0200
        message:
          Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON
          GRACEFUL SHUTDOWN
          
          During startup mysql picks up .frm files from the tmpdir directory and
          tries to drop those tables in the storage engine.
          
          The problem is that when tmpdir ends in / then ha_innobase::delete_table()
          is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it
          to "/#sql123" and calls row_drop_table_for_mysql() which of course fails
          to delete the table entry from the InnoDB dictionary cache.
          ha_innobase::delete_table() returns an error but nevertheless mysql wipes
          away the .frm file and the entry in the InnoDB dictionary cache remains
          orphaned with no easy way to remove it.
          
          The "no easy" way to remove it is to create a similar temporary table again,
          copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with
          tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file
          after restart and will try to issue drop table for "/var/tmp/#sql123"
          (notice do double slash), ha_innobase::delete_table() will normalize it to
          "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the
          table entry from the dictionary cache.
          
          The solution is to fix normalize_table_name_low() to normalize things like
          "/var/tmp//table" correctly to "tmp/table".
          
          This patch also adds a test function which invokes
          normalize_table_name_low() with various inputs to make sure it works
          correctly and a mtr test that calls this test function.
          
          Reviewed by:	Marko (http://bur03.no.oracle.com/rb/r/929/)
        ------------------------------------------------------------
        revno: 2555.936.103
        committer: Ashish Agarwal<ashish.y.agarwal@oracle.com>
        branch nick: bug_93_5.1
        timestamp: Fri 2012-02-03 19:37:00 +0530
        message:
          BUG#11748748 - 37280: CHECK AND REPAIR TABLE REPORT TABLE
                                CORRUPTED WHEN RUN CONCURRENTLY WITH
          
          ISSUE: Table corruption due to concurrent queries.
                 Different threads running check, repair query
                 along with insert. Locks not properly acquired
                 in repair query. Rows are inserted inbetween
                 repair query.
          
          SOLUTION: Mutex lock is acquired before the
                    repair call. Concurrent queries wont
                    effect the call to repair.
        ------------------------------------------------------------
        revno: 2555.936.102
        committer: Alexander Barkov <alexander.barkov@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-02 16:22:13 +0400
        message:
          Postfix for Bug#11752408.
          Recording correct test results.
          
          modified:
            mysql-test/suite/engines/funcs/r/db_alter_collate_ascii.result
            mysql-test/suite/engines/funcs/r/db_alter_collate_utf8.result
        ------------------------------------------------------------
        revno: 2555.936.101
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-02 13:38:32 +0200
        message:
          Bug#13654923 BOGUS DEBUG ASSERTION IN INDEX CREATION FOR ZERO-LENGTH RECORD
          
          row_merge_buf_write(): Relax the bogus assertion.
        ------------------------------------------------------------
        revno: 2555.936.100
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-02 12:07:06 +0200
        message:
          Suppress messages about long semaphore waits in innodb_bug34300.test.
        ------------------------------------------------------------
        revno: 2555.936.99 [merge]
        committer: Ashish Agarwal<ashish.y.agarwal@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-02-02 14:19:38 +0530
        message:
          BUG#11756869 - 48848: MYISAMCHK DOING SORT RECOVER IN CERTAIN
                                CASES RESETS DATA POINTER TO SMAL
          
          ISSUE: Myisamchk doing sort recover
                 on a table reduces data_file_length.
                 Maximum size of data file decreases,
                 lesser number of rows are stored.
          
          SOLUTION: Size of data_file_length is
                    fixed to the original length.
            ------------------------------------------------------------
            revno: 2555.950.1
            committer: Ashish Agarwal<ashish.y.agarwal@oracle.com>
            branch nick: bug_869_1
            timestamp: Wed 2012-02-01 11:19:53 +0530
            message:
              BUG#11756869 - 48848: MYISAMCHK DOING SORT RECOVER IN CERTAIN
                                    CASES RESETS DATA POINTER TO SMAL
              
              ISSUE: Myisamchk doing sort recover
                     on a table reduces data_file_length.
                     Maximum size of data file decreases,
                     lesser number of rows are stored.
              
              SOLUTION: Size of data_file_length is
                        fixed to the original length.
        ------------------------------------------------------------
        revno: 2555.936.98
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-01-31 09:31:31 -0500
        message:
          Bug#13636122 THE ORIGINAL TABLE MISSING WHILE EXECUTE THE DDL 'ALTER TABLE ADD COLUMN
          
          rb://914
          approved by: Marko Makela
          
          Poll in fil_rename_tablespace() after setting ::stop_ios flag can
          result in a hang because the other thread actually dispatching the IO
          won't wake IO helper threads or flush the tablespace before starting
          wait in fil_mutex_enter_and_prepare_for_io().
        ------------------------------------------------------------
        revno: 2555.936.97
        committer: sayantan.dutta@oracle.com
        branch nick: mysql-5.1
        timestamp: Tue 2012-01-31 17:39:40 +0530
        message:
          (no message)
        ------------------------------------------------------------
        revno: 2555.936.96
        committer: sayantan.dutta@oracle.com
        branch nick: mysql-5.1
        timestamp: Tue 2012-01-31 17:09:32 +0530
        message:
          Bug #64127: MTR --warnings option misses some of InnoDB errors and warnings
        ------------------------------------------------------------
        revno: 2555.936.95 [merge]
        committer: Ramil Kalimullin <ramil@mysql.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-01-31 10:57:12 +0400
        message:
          Null-merge from mysql-5.0.
            ------------------------------------------------------------
            revno: 1810.3999.18
            committer: Ramil Kalimullin <ramil@mysql.com>
            branch nick: mysql-5.0
            timestamp: Mon 2012-01-30 22:52:33 +0400
            message:
              Fix for BUG#13596377: MYSQL CRASHES ON STARTUP ON FREEBSD IN PB2
              
              Fix for #36428/#38364 backported into 5.0.
        ------------------------------------------------------------
        revno: 2555.936.94
        committer: Guilhem Bichot <guilhem.bichot@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2012-01-26 10:25:23 +0100
        message:
          Fixes for:
          BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND
          WITH/WITHOUT INDEX RANGE SCAN
          BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG
          RESULTS WITH DECIMAL CONVERSION
          BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG
          RESULT AFTER MYSQL 5.1.
          Those are all cases where the range optimizer got it wrong
          with > and >=.
        ------------------------------------------------------------
        revno: 2555.936.93
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2012-01-25 10:15:27 +0200
        message:
          btr_cur_search_to_nth_level(): Add a debug assertion
          and some Valgrind instrumentation.
        ------------------------------------------------------------
        revno: 2555.936.92 [merge]
        committer: Alexander Barkov <alexander.barkov@oracle.com>
        branch nick: mysql-5.1.b13458237
        timestamp: Tue 2012-01-24 16:02:12 +0400
        message:
          Merging from mysql-5.1
            ------------------------------------------------------------
            revno: 2555.949.1
            committer: Alexander Barkov <alexander.barkov@oracle.com>
            branch nick: mysql-5.1.b11752408
            timestamp: Mon 2012-01-23 13:07:10 +0400
            message:
              Bug#11752408 - 43593: DUMP/BACKUP/RESTORE/UPGRADE TOOLS FAILS BECAUSE OF UTF8_GENERAL_CI
              
              Introducing new collations:
              utf8_general_mysql500_ci and ucs2_general_mysql500_ci,
              to reproduce behaviour of utf8_general_ci and ucs2_general_ci
              from mysql-5.1.23 (and earlier).
              
              The collations are added to simplify upgrade from mysql-5.1.23 and earlier.
              
              Note: The patch does not make new server start over old data automatically.
              Some manual upgrade procedures are assumed.
              
              Paul: please get in touch with me to discuss upgrade procedures
              when documenting this bug.
              
              modified:
                include/m_ctype.h
                mysql-test/r/ctype_utf8.result
                mysql-test/t/ctype_utf8.test
                mysys/charset-def.c
                strings/ctype-ucs2.c
                strings/ctype-utf8.c
        ------------------------------------------------------------
        revno: 2555.936.91
        committer: Alexander Barkov <alexander.barkov@oracle.com>
        branch nick: mysql-5.1.b13458237
        timestamp: Tue 2012-01-24 13:00:13 +0400
        message:
          BUG#13458237 - INCONSISTENT HANDLING OF INVALIDE DATES WITH ZERO DAY. SIMILAR TO '2009-10-00' 
          - Reverting the patch for Bug # 12584302
            The patch will be reverted in 5.1 and 5.5.
            The patch will not be reverted in 5.6, the change will
            be properly documented in 5.6.
          - Backporting DBUG_ASSERT not to crash on '0000-01-00'
            (already fixed in mysql-trunk (5.6))
        ------------------------------------------------------------
        revno: 2555.936.90
        committer: Nirbhay Choubey <nirbhay.choubey@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-01-17 09:10:58 +0530
        message:
          Bug #11760384 52792: MYSQLDUMP IN XML MODE DOES NOT
                               DUMP ROUTINES
          
          Minor post-fix to avoid build failure when built with
          Werror.
        ------------------------------------------------------------
        revno: 2555.936.89
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-01-16 14:22:03 +0200
        message:
          Bug#13496818 ASSERTION: REC_PAGE_NO > 4 IN IBUF CONTRACTION
          Relax a bogus debug assertion.
          Approved by Jimmy Yang on IM.
        ------------------------------------------------------------
        revno: 2555.936.88
        committer: Nuno Carvalho <nuno.carvalho@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-01-16 09:17:40 +0000
        message:
          BUG#11893288 60542: RPL.RPL_EXTRA_COL_MASTER_* DOESN'T TEST WHAT WAS INTENDED
          
          Test extra/rpl_tests/rpl_extra_col_master.test (used by
          rpl_extra_col_master_*) ends with the active connection pointing to the
          slave. Thus, the two last tests never succeed in changing the binlog
          format of the master away from 'row'. With correct active connection
          (master) tests fail for binlog 'statement' and 'mixed' formats.
          
          Tests rpl_extra_col_master_* only run when binary log format is
          row.  Statement and mix replication do not make sense in this
          tests since it will try to execute statements on columns that do
          not exist.  This fix is basically a backport from mysql-5.5, see
          changes done as part of BUG 39934.
        ------------------------------------------------------------
        revno: 2555.936.87
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2012-01-16 09:55:12 +0200
        message:
          buf_page_get_known_nowait(): Relax a bogus debug assertion.
          When mode==BUF_KEEP_OLD, buffered inserts are being merged to the page.
          It is possible that a read request for a page was pending while the page
          was freed in DROP INDEX or DROP TABLE. In these cases, it is OK (although
          useless) to merge the buffered changes to the freed page.
        ------------------------------------------------------------
        revno: 2555.936.86
        committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
        branch nick: mysql-5.1-bug11765438
        timestamp: Mon 2012-01-16 09:58:31 +0530
        message:
          Bug #11765438 58406: 
          ISSUES WITH COPYING PARTITIONED INNODB TABLES FROM LINUX TO WINDOWS
          
          This problem was already fixed in mysql-trunk as part of bug #11755924.  I am 
          backporting the fix to mysql-5.1.  
    ------------------------------------------------------------
    revno: 2555.948.9
    committer: Gopal Shankar <gopal.shankar@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Mon 2012-01-30 11:57:33 +0530
    message:
            Bug#13105873 :Valgrind Warning: CRASH IN FOREIGN
            KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS
            
            PROBLEM:
            --------
            Consider a SP routine which does CREATE TABLE
            with REFERENCES clause. The first call to this routine
            invokes parser and the parsed items are cached, so as 
            to avoid parsing for the second execution of the routine.
            
            It is obsevered that valgrind reports a warning
            upon read of thd->lex->alter_info->key_list->Foreign_key object,
            which seem to be pointing to a invalid memory address
            during second time execution of the routine. Accessing this object
            theoretically could cause a crash.
            
            ANALYSIS:
            ---------
            The problem stems from the fact that for some reason
            elements of ref_columns list in thd->lex->alter_info->
            key_list->Foreign_key object are changed to point to
            objects allocated on runtime memory root.
            
            During the first execution of routine we create
            a copy of thd->lex->alter_info object.
            As part of this process we create a clones of objects in
            Alter_info::key_list and of Foreign_key object in particular.
            Then Foreign_key object is cloned for some reason we
            perform shallow copies of both Foreign_key::ref_columns
            and Foreign_key::columns list. So new instance of 
            Foreign_key object starts to SHARE contents of ref_columns
            and columns list with the original instance.
            After that as part of cloning process we call
            list_copy_and_replace_each_value() for elements of
            ref_columns list. As result ref_columns lists in both
            original and cloned Foreign_key object start to contain
            pointers to Key_part_spec objects allocated on runtime
            memory root because of shallow copy.
            
            So when we start copying of thd->lex->alter_info object
            during the second execution of stored routine we indeed
            encounter pointer to the Key_part_spec object allocated
            on runtime mem-root which was cleared during at the end
            of previous execution. This is done in sp_head::execute(), 
            by a call to free_root(&execute_mem_root,MYF(0));
            As result we get valgrind warnings about accessing 
            unreferenced memory.
            
            FIX:
            ----
            The safest solution to this problem is to 
            fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do
            a deep copy of columns lists, similar to Key(Key, MEM_ROOT) 
            constructor.
    ------------------------------------------------------------
    revno: 2555.948.8
    committer: Tor Didriksen <tor.didriksen@oracle.com>
    branch nick: 5.1-security
    timestamp: Fri 2012-01-27 11:13:13 +0100
    message:
      Bug#13580775 ASSERTION FAILED: RECORD_LENGTH == M_RECORD_LENGTH
      Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP
      
      The assert in 13580775 is visible in 5.6 only, 
      but shows that all versions are vulnerable.
      13011410 crashes in all versions.
      
      filesort tries to re-use the sort buffer between invocations in order to save
      malloc/free overhead.
      The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT.
      added an assert that buffer properties (num_records, record_length) are
      consistent between invocations. Indeed, they are not necessarily consistent.
        
      Fix: re-allocate the sort buffer if properties change.
    ------------------------------------------------------------
    revno: 2555.948.7 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Thu 2012-01-12 16:43:41 +0200
    message:
      empty weave merge mysql-5.0-security->mysql-5.1-security
        ------------------------------------------------------------
        revno: 1810.4002.30 [merge]
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: merge-5.0-security
        timestamp: Thu 2012-01-12 16:39:44 +0200
        message:
          empty weave merge from mysql-5.0
    ------------------------------------------------------------
    revno: 2555.948.6 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Thu 2012-01-12 16:42:23 +0200
    message:
      weave merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.85 [merge]
        committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
        branch nick: merge-5.1
        timestamp: Thu 2012-01-12 14:57:14 +0200
        message:
          empty weave merge
            ------------------------------------------------------------
            revno: 1810.3999.17 [merge]
            committer: Bjorn Munch <bjorn.munch@oracle.com>
            branch nick: mysql-5.0
            timestamp: Wed 2012-01-11 10:10:34 +0100
            message:
              Merge from mysql-5.0.95-release
        ------------------------------------------------------------
        revno: 2555.936.84 [merge]
        committer: Karen Langford <karen.langford@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2012-01-11 18:51:42 +0100
        message:
          Merge from mysql-5.1.61-release
        ------------------------------------------------------------
        revno: 2555.936.83
        committer: Nirbhay Choubey <nirbhay.choubey@oracle.com>
        branch nick: mysql-5.1.52792
        timestamp: Tue 2012-01-10 13:33:45 +0530
        message:
          BUG#11760384 - 52792: mysqldump in XML mode does not dump
                               routines.
          
          mysqldump in xml mode did not dump routines, events or
          triggers.
          
          This patch fixes this issue by fixing the if conditions
          that disallowed the dump of above mentioned objects in
          xml mode, and added the required code to enable dump
          in xml format.
        ------------------------------------------------------------
        revno: 2555.936.82
        committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2012-01-10 14:18:58 +0900
        message:
          Bug#12400341 INNODB CAN LEAVE ORPHAN IBD FILES AROUND
          
          If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling.
          
          rb:875 approved by Jimmy Yang
        ------------------------------------------------------------
        revno: 2555.936.81
        committer: Hemant Kumar <hemant.hk.kumar@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2012-01-06 16:28:24 +0530
        message:
          Bug#12872803 - 62154: FEDERATED.FEDERATED_SERVER TEST FAILS WITH RUN --REPEAT=2
          Fixed it to work with "--repeat" option.
        ------------------------------------------------------------
        revno: 2555.936.80
        committer: Hemant Kumar <hemant.hk.kumar@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2012-01-06 15:46:03 +0530
        message:
          Bug#12872804 - 62155: BINLOG.BINLOG_STM_UNSAFE_WARNING FAILS WHEN RUN WITH --REPEAT=2
          Fixed the testcase using timestamp logic while doing grep from the error file.
        ------------------------------------------------------------
        revno: 2555.936.79
        committer: Tatjana Azundris Nuernberg <tatjana.nuernberg@oracle.com>
        branch nick: 51-11755281
        timestamp: Mon 2012-01-02 06:25:48 +0000
        message:
          BUG#11755281/47032: ERROR 2006 / ERROR 2013 INSTEAD OF PROPER ERROR MESSAGE
          
          If init_command was incorrect, we couldn't let users execute
          queries, but we couldn't report the issue to the client either
          as it does not expect error messages before even sending a
          command. Thus, we simply disconnected them without throwing
          a clear error.
          
          We now go through the proper sequence once (without executing
          any user statements) so we can report back what the problem
          is. Only then do we disconnect the user.
          
          As always, root remains unaffected by this as init_command is
          (still) not executed for them.
        ------------------------------------------------------------
        revno: 2555.936.78
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2011-12-28 12:19:30 +0200
        message:
          Bug#13418934 REMOVE HAVE_PURIFY DEPENDENCES FROM INNODB
          
          InnoDB: Remove HAVE_purify, UNIV_INIT_MEM_TO_ZERO, UNIV_SET_MEM_TO_ZERO.
          
          The compile-time setting HAVE_purify can mask potential bugs.
          It is being set in PB2 Valgrind runs. We should simply get rid of it,
          and replace it with UNIV_MEM_INVALID() to declare uninitialized memory
          as such in Valgrind-instrumented binaries.
          
          os_mem_alloc_large(), ut_malloc_low(): Remove the parameter set_to_zero.
          
          ut_malloc(): Define as a macro that invokes ut_malloc_low().
          
          buf_pool_init(): Never initialize the buffer pool frames. All pages
          must be initialized before flushing them to disk.
          
          mem_heap_alloc(): Never initialize the allocated memory block.
          
          os_mem_alloc_nocache(), ut_test_malloc(): Unused function, remove.
          
          rb:813 approved by Jimmy Yang
        ------------------------------------------------------------
        revno: 2555.936.77
        committer: Ramil Kalimullin <ramil@mysql.com>
        branch nick: mysql-5.1
        timestamp: Fri 2011-12-23 18:52:44 +0400
        message:
          Fix for bug#11758931 - 51196: SLAVE SQL: GOT AN ERROR WRITING
          COMMUNICATION PACKETS, ERROR_CODE: 1160
          
          Addendum: for some queries table->in_use might be NULL -
          check it.
        ------------------------------------------------------------
        revno: 2555.936.76
        committer: Ramil Kalimullin <ramil@mysql.com>
        branch nick: mysql-5.1
        timestamp: Fri 2011-12-23 17:22:48 +0400
        message:
          Fix for bug#11758931 - 51196: SLAVE SQL: GOT AN ERROR WRITING 
          COMMUNICATION PACKETS, ERROR_CODE: 1160
          
          If idle FEDERATED table is evicted from the table cache when 
          a connection to remote server is lost, query that initiated 
          eviction may fail.
          If this query is executed by slave SQL thread it may fail as well.
          
          An error of close was stored in diagnostics area, which was later
          attributed to the statement that caused eviction.
          
          With this patch FEDERATED clears an error of close.
        ------------------------------------------------------------
        revno: 2555.936.75
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2011-12-21 21:36:52 -0500
        message:
          Add ChangeLog message.
        ------------------------------------------------------------
        revno: 2555.936.74
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2011-12-21 21:33:13 -0500
        message:
          Bug#11866367	FPE WHEN SETTING INNODB_SPIN_WAIT_DELAY
          
          rb://865
          approved by: Jimmy
          
          Integer overflow causes division by zero.
    ------------------------------------------------------------
    revno: 2555.948.5
    committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Mon 2012-01-09 11:28:02 +0100
    message:
      Backport from mysql-trunk of:
      ------------------------------------------------------------
      revno: 3258
      committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
      branch nick: mysql-trunk-bug12663165
      timestamp: Thu 2011-07-14 10:05:12 +0200
      message:
        Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS
        
        When stored routines are loaded, a simple optimizer tries to locate
        and remove dead code. The problem was that this dead code removal
        did not work correctly with CONTINUE handlers.
        
        If a statement triggers a CONTINUE handler, the following statement
        will be executed after the handler statement has completed. This
        means that the following statement is not dead code even if the
        previous statement unconditionally alters control flow. This fact
        was lost on the dead code removal routine, which ended up with
        removing instructions that could have been executed. This could
        then lead to assertions, crashes and generally bad behavior when
        the stored routine was executed.
        
        This patch fixes the problem by marking as live code all stored
        routine instructions that are in the same scope as a CONTINUE handler.
        
        Test case added to sp.test.
    ------------------------------------------------------------
    revno: 2555.948.4
    committer: Vasil Dimov <vasil.dimov@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Thu 2011-12-22 12:55:44 +0200
    message:
      Fix Bug#13510739 63775: SERVER CRASH ON HANDLER READ NEXT AFTER DELETE RECORD.
      
      CREATE TABLE bug13510739 (c INTEGER NOT NULL, PRIMARY KEY (c)) ENGINE=INNODB;
      INSERT INTO bug13510739 VALUES (1), (2), (3), (4);
      DELETE FROM bug13510739 WHERE c=2;
      HANDLER bug13510739 OPEN;
      HANDLER bug13510739 READ `primary` = (2);
      HANDLER bug13510739 READ `primary` NEXT;  <-- crash
      
      The bug is that in the particular testcase row_search_for_mysql() picked up
      a delete-marked record and quit, leaving the cursor non-positioned state and
      on the subsequent 'get next' call the code crashed because of the
      non-positioned cursor.
      
      In row0sel.cc (line numbers from mysql-trunk):
      
      4653         if (rec_get_deleted_flag(rec, comp)) {
      ...
      4679                 if (index == clust_index && unique_search) {
      4680 
      4681                         err = DB_RECORD_NOT_FOUND;
      4682                         
      4683                         goto normal_return;
      4684                 }       
      
      it quit from here, not storing the cursor position.
      
      In contrast, if the record=2 is not found at all (e.g. sleep(1) after DELETE
      to let the purge wipe it away completely) then 'get = 2' does find record=3
      and quits from here:
      
      4366                 if (0 != cmp_dtuple_rec(search_tuple, rec, offsets)) {
      ...
      4394                         btr_pcur_store_position(pcur, &mtr);
      4395 
      4396                         err = DB_RECORD_NOT_FOUND;
      4397 #if 0
      4398                         ut_print_name(stderr, trx, FALSE, index->name);
      4399                         fputs(" record not found 3\n", stderr);
      4400 #endif
      4401 
      4402                         goto normal_return;
      
      Another fix could be to extend the condition on line 4366 to hold only if
      seach_tuple matches rec AND if rec is not delete marked.
      
      Notice that in the above test case if we wait about 1 second somewhere after
      DELETE and before 'get = 2', then the testcase does not crash and returns 4
      instead. Not sure if this is the correct behavior, but this bugfix removes
      the crash and makes the code return what it also returns in the non-crashing
      case (if rec=2 is not found during 'get = 2', e.g. we have sleep(1) there).
      
      Approved by:	Marko (http://bur03.no.oracle.com/rb/r/863/)
    ------------------------------------------------------------
    revno: 2555.948.3 [merge]
    committer: Joerg Bruehe <joerg.bruehe@oracle.com>
    branch nick: security-5.1
    timestamp: Fri 2011-12-16 12:54:28 +0100
    message:
      Empty merge (alignment of version number changesets).
        ------------------------------------------------------------
        revno: 1810.4002.29 [merge]
        committer: Joerg Bruehe <joerg.bruehe@oracle.com>
        branch nick: security-5.0
        timestamp: Fri 2011-12-16 12:51:47 +0100
        message:
          Empty merge of identical version number changes.
        ------------------------------------------------------------
        revno: 1810.4002.28
        author: joerg.bruehe@oracle.com
        committer: Build Team <MYSQL-RE_WW@oracle.com>
        branch nick: mysql-5.0-security
        timestamp: Fri 2011-12-16 12:22:47 +0100
        message:
          Raise version number after cloning 5.0.95
    ------------------------------------------------------------
    revno: 2555.948.2 [merge]
    committer: Joerg Bruehe <joerg.bruehe@oracle.com>
    branch nick: security-5.1
    timestamp: Fri 2011-12-16 12:50:07 +0100
    message:
      Empty merge of version number changes.
        ------------------------------------------------------------
        revno: 2555.936.73 [merge]
        committer: Joerg Bruehe <joerg.bruehe@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2011-12-16 12:39:10 +0100
        message:
          Empty upmerge of a 5.0 version number increase.
            ------------------------------------------------------------
            revno: 1810.3999.16
            committer: Joerg Bruehe <joerg.bruehe@oracle.com>
            branch nick: mysql-5.0
            timestamp: Fri 2011-12-16 12:33:54 +0100
            message:
              Raise version number after cloning 
        ------------------------------------------------------------
        revno: 2555.936.72
        committer: Joerg Bruehe <joerg.bruehe@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2011-12-16 12:31:57 +0100
        message:
          Raise version number after cloning 
    ------------------------------------------------------------
    revno: 2555.948.1
    author: joerg.bruehe@oracle.com
    committer: Build Team <MYSQL-RE_WW@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Fri 2011-12-16 12:24:05 +0100
    message:
      Raise version number after cloning 5.1.61
------------------------------------------------------------
revno: 3484
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Thu 2012-09-13 21:18:47 +0100
message:
  Bug #14472648 	CONFIGURED DISKCHECKPOINTSPEED EXCEEDED WHEN BACKUPMAXWRITESIZE SET TO HIGH VALU
  
  The DiskCheckpointSpeed mechanism is implemented using 100 millisecond
  periods, which each have 1/10th of the configured quota available.
  
  A period is allowed to overflow its quota, with the excess being taken 
  from the next period's quota.
  
  However, this overflow was limited to the next period, after that, any
  further overflow was ignored.
  
  In cases where large overflows were possible, relative to the 1/10 
  DiskCheckPointSpeed quota, this could result in excessive disk writing,
  and CPU overhead as a result.
  
  Setting a larger-than standard MaxBackupWriteSize is the primary means
  of causing larger-than 2* quota overflows and triggering this bug.
  
  This bug is fixed by using as many subsequent periods as necessary to
  'pay off' the quota overflow.
  
  This will result in the data node staying within its quota.
  
  This fix may result in slower LCP in some systems, and reduced CPU usage
  during LCP.
  
  A testcase, and an internal DiskCheckPointSpeed verification mechanism
  are added to avoid future regressions.
------------------------------------------------------------
revno: 3483
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Wed 2012-09-12 14:24:49 +0100
message:
  Bug #14386849 	SCAN RESOURCE LEAK WHEN TC KEYINFO DATA BUFFERS EXHAUSTED
  
  This patch fixes the scan resources leak when TC KeyInfo data buffers are exhausted.
  
  A testcase is added - one which causes a real leak, another which simulates it.
  
  Two new dump commands are added, to give visibility of the pool levels in TC and LQH.
------------------------------------------------------------
revno: 3482
committer: magnus.blaudd@oracle.com
branch nick: 6.3
timestamp: Wed 2012-09-12 13:12:19 +0200
message:
  Fix test case failure which depends on the binlogs content by adjusting
  the used binlog position
------------------------------------------------------------
revno: 3481
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Tue 2012-08-21 09:20:27 +0200
message:
  ndb - bump version to 6.3.50
------------------------------------------------------------
revno: 3480
tags: clone-mysql-5.1.61-ndb-6.3.49-src-build
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-08-13 16:00:28 +0100
message:
  Fix compile failure
------------------------------------------------------------
revno: 3479
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Mon 2012-08-13 12:03:25 +0100
message:
  Bug #14389746 INCOMPLETE REDO METADATA RELOAD LEADS TO REDO EXHAUSTION
  
  Fix problem with redo log metadata reload at node or system restart.
  
  The redo metadata reload mechanism is modified to avoid reading invalid
  data.  This avoids later problems when iterating over this metadata. 
  
  A new test program (testRedo) is created, and added to the daily-basic 
  suite.
------------------------------------------------------------
revno: 3478
committer: Jan Wedvik <jan.wedvik@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Tue 2012-06-26 14:26:28 +0200
message:
  Fixing Windows build break.
------------------------------------------------------------
revno: 3477
committer: Jan Wedvik <jan.wedvik@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Tue 2012-06-26 11:00:13 +0200
message:
  Patch updated according to suggestions from Magnus Bl?udd and Fraqzer Clement.
  
  This is a fix for bug#11748194 "TRANSACTION OBJECT CREATED AND UNRELEASED BY 
  EXTRA CALL TO NEXTRESULT()".
  
  This bug had the following effect: If an API application tried calling 
  NdbScanOperation::nextResult() once more when the previous call had retuned
  end-of-file (return code 1), the api would leak a transaction object.
  
  This commit fixes that problem. Ndb::closeTransaction() will now put the
  extra transaction object associated with the scan back in the idle list
  for the right TC node.
  
  Also, calling NdbScanOperation::nextResult() once too much will now set
  a proper error code (4210), instead of the undefined code -1.
  
  Finally, this commit adds a regression test that will trigger the bug if the
  bugfix is not applied.
------------------------------------------------------------
revno: 3476
committer: Jan Wedvik <jan.wedvik@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Thu 2012-06-21 12:31:29 +0200
message:
  This is a fix for bug#14208924 . It is based on an initial patch written by 
  Frazer Clement.
  
  If TC decides to abort a transaction in the 'prepared' state, it may leak 
  ApiConnectRecord objects that was allocated via Dbtc::seizeApiConnectCopy(). 
  These are normally released by Dbtc::sendApiCommit() followed by
  Dbtc::releaseApiConCopy(). If the transaction aborts, these methods are not 
  called.
  
  This patch fixes the above issue by checking if the ApiConnectRecord object
  has an apiCopyRecord when the transaction aborts. If so, the copy object is put
  back in the free list.
  
  The patch also adds a regression test case (using an error insert).
------------------------------------------------------------
revno: 3475
committer: Martin Skold <Martin.Skold@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Thu 2012-06-21 12:05:18 +0200
message:
  Bug#12755722  61528: INNODB BACKEND CRASHES ON ALTER TABLE STATEMENT (MYSQL SERVER HAS GONE AWAY: implemented check for new field and added test case
------------------------------------------------------------
revno: 3474
committer: Pekka Nousiainen <pekka.nousiainen@oracle.com>
branch nick: ms-bug13834481-63
timestamp: Thu 2012-05-03 12:52:53 +0300
message:
  bug#13834481 b01_upg.diff
  testUpgrade failing before 7.0 patches
------------------------------------------------------------
revno: 3473
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Tue 2012-04-24 16:07:32 +0100
message:
  Bug #13986128 DUMP LCP RESERVED FRAGMENT SCAN RECORD AS PART OF LCP STATUS DUMP
------------------------------------------------------------
revno: 3472
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Tue 2012-04-24 11:55:03 +0100
message:
  Bug#13966723 MYSQL CLUSTER - CONCURRENT OPERATIONS 'LEAK' RESULTS IN "TOO MANY ACTIVE SCANS"
  
  TC had a bug where a shortage of TC scan fragment records resulted in
  a leak of scan table records and key operations.
  
  This is fixed, and a testcase added.
------------------------------------------------------------
revno: 3471
committer: memontgo <memontgo@memontgo-vmOEL6>
branch nick: mysql-5.1-telco-6.3
timestamp: Wed 2012-03-21 16:44:05 -0500
message:
  bug#13364905 / bug#62635 - Add support for --hostname=host:port format to ndb_size.pl 
------------------------------------------------------------
revno: 3470
committer: Frazer Clement <frazer.clement@oracle.com>
branch nick: mysql-5.1-telco-6.3
timestamp: Wed 2012-03-21 14:45:39 +0000
message:
  Empty commit
------------------------------------------------------------
revno: 3469
committer: Jonas Oreland <jonas.oreland@oracle.com>
branch nick: telco-6.3
timestamp: Mon 2012-03-12 10:36:33 +0100
message:
  ndb - bump version to 6.3.49
------------------------------------------------------------
revno: 3468 [merge]
tags: clone-mysql-5.1.61-ndb-6.3.48-src-build
committer: jonas oreland <jonas.oreland@oracle.com>
branch nick: telco-6.3
timestamp: Mon 2012-02-13 18:00:22 +0100
message:
  ndb - merge 5.1.61 into 6.3
    ------------------------------------------------------------
    revno: 2555.947.8
    tags: mysql-5.1.61
    committer: Karen Langford <karen.langford@oracle.com>
    branch nick: mysql-5.1.61-release
    timestamp: Wed 2012-01-11 18:40:29 +0100
    message:
      Fixes required to build on AIX
    ------------------------------------------------------------
    revno: 2555.947.7
    tags: clone-5.1.61-build
    committer: Mattias Jonsson <mattias.jonsson@oracle.com>
    branch nick: topush-5.1-sec
    timestamp: Thu 2011-12-15 16:59:18 +0100
    message:
      Post push fix for merge.test and mysqlcheck.test on windows
    ------------------------------------------------------------
    revno: 2555.947.6 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Thu 2011-12-15 14:10:20 +0200
    message:
      merge mysql-5.1->mysql-5.1-security
        ------------------------------------------------------------
        revno: 2555.936.71
        committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>
        branch nick: mysql-5.1-bug13117023
        timestamp: Tue 2011-12-13 14:26:12 +0530
        message:
          Bug #13117023: Innodb increments handler_read_key when it should not
          
          The counter handler_read_key (SSV::ha_read_key_count) is incremented 
          incorrectly.
          
          The mysql server maintains a per thread system_status_var (SSV)
          object.  This object contains among other things the counter
          SSV::ha_read_key_count. The purpose of this counter is to measure the
          number of requests to read a row based on a key (or the number of
          index lookups).
          
          This counter was wrongly incremented in the
          ha_innobase::innobase_get_index(). The fix removes
          this increment statement (for both innodb and innodb_plugin).
          
          The various callers of the innobase_get_index() was checked to
          determine if anybody must increment this counter (if they first call
          innobase_get_index() and then perform an index lookup).  It was found
          that no caller of innobase_get_index() needs to worry about the
          SSV::ha_read_key_count counter.
        ------------------------------------------------------------
        revno: 2555.936.70
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2011-12-12 13:48:24 +0200
        message:
          Bug#13418887 ERROR IN DIAGNOSTIC FUNCTION PAGE_REC_PRINT()
          
          When printing information about a ROW_FORMAT=REDUNDANT record, pass
          the correct flag to rec_get_next_offs().
          
          rb:821 approved by Jimmy Yang
    ------------------------------------------------------------
    revno: 2555.947.5 [merge]
    committer: Mattias Jonsson <mattias.jonsson@oracle.com>
    branch nick: topush-5.1-sec
    timestamp: Wed 2011-12-14 14:41:40 +0100
    message:
      merge
        ------------------------------------------------------------
        revno: 1810.4002.27 [merge]
        tags: mysql-5.0.95, clone-5.0.95-build
        committer: Mattias Jonsson <mattias.jonsson@oracle.com>
        branch nick: topush-5.0-sec
        timestamp: Wed 2011-12-14 14:05:22 +0100
        message:
          merge
            ------------------------------------------------------------
            revno: 1810.4004.1
            committer: Mattias Jonsson <mattias.jonsson@oracle.com>
            branch nick: b12361113-50-sec
            timestamp: Mon 2011-12-12 14:07:02 +0100
            message:
              Bug#12361113: CRASH WHEN "LOAD INDEX INTO CACHE" WITH TOO
              SMALL KEY CACHE
              
              The server crashed on division by zero because the key cache was not
              initialized and the block length was 0 which was used in a division.
              
              The fix was to not allow CACHE INDEX if the key cache was not initiallized.
              Thus never try LOAD INDEX INTO CACHE for an uninitialized key cache.
              
              Also added some windows files/directories to .bzrignore.
    ------------------------------------------------------------
    revno: 2555.947.4 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Mon 2011-12-12 12:25:35 +0100
    message:
      merge 5.1->5.1-security.
        ------------------------------------------------------------
        revno: 2555.936.69
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1-sighandler
        timestamp: Wed 2011-11-30 17:11:13 +0100
        message:
          Bug#11761576 54082: HANDLE_SEGFAULT MAKES USE OF UNSAFE FUNCTIONS
          
          Post-push fix: build break on windows/optimized
        ------------------------------------------------------------
        revno: 2555.936.68
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1-sighandler
        timestamp: Wed 2011-11-30 15:39:29 +0100
        message:
          Bug#11761576 54082: HANDLE_SEGFAULT MAKES USE OF UNSAFE FUNCTIONS
          
          handle_segfault is the signal handler code of mysqld.  however, it makes
          calls to potentially unsafe functions localtime_r, fprintf, fflush.
        ------------------------------------------------------------
        revno: 2555.936.67
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1
        timestamp: Tue 2011-11-29 15:52:47 +0100
        message:
          Build broken for gcc 4.5.1 in optimized mode.
          
          readline.cc: In function char* batch_readline(LINE_BUFFER*):
          readline.cc:60:9: error: out_length may be used uninitialized in this function
          log.cc: In function int find_uniq_filename(char*):
          log.cc:1857:8: error: number may be used uninitialized in this function
        ------------------------------------------------------------
        revno: 2555.936.66
        committer: Nirbhay Choubey <nirbhay.choubey@oracle.com>
        branch nick: B11756764-5.1
        timestamp: Tue 2011-11-29 17:59:35 +0530
        message:
          Bug#11756764 48726: MYSQLD KEEPS CRASHING WITH SIGSEGV
                              WITH MYISAM_USE_MMAP ENABLED
          
          MySQL server can crash due to segmentation fault when
          started with myisam_use_mmap.
          
          The reason behind this being, while making a request to
          unmap (munmap) the previously mapped memory (mmap), the
          size passed was 7 bytes larger than the size requested at
          the time of mapping. This can eventually unmap the adjacent
          memory mapped block, belonging to some other memory-map pool.
          Hence the subsequent call to mmap can map a region which was
          still a valid memory mapped area.
          
          Fixed by removing the extra 7-byte margin which was erroneously
          added to the size, used for unmappping.
        ------------------------------------------------------------
        revno: 2555.936.65
        committer: Ashish Agarwal<ashish.y.agarwal@oracle.com>
        branch nick: bug_93_5.1
        timestamp: Wed 2011-11-23 18:33:29 +0530
        message:
          BUG#11751793 - 42784: ARCHIVE TABLES CAUSE 100% CPU USAGE
                                AND HANG IN SHOW TABLE STATUS.
          
          ISSUE: Table corruption due to concurrent queries.
                 Different threads running insert and check
                 query leads to table corruption. Not properly locked,
                 rows are inserted in between check query.
          
          SOLUTION: In check query mutex lock is acquired
                    for a longer time to handle concurrent
                    insert and check query.
          
          NOTE: Additionally we backported the fix for CHECKSUM
                issue(bug#11758979).
        ------------------------------------------------------------
        revno: 2555.936.64
        committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
        branch nick: mysql-5.1-test
        timestamp: Tue 2011-11-22 14:16:13 +0100
        message:
          Disabling main.query_cache_28249.test since this test fails
          sporadically on 5.1. See Bug#12584161.
          
          Test runs successfully on 5.5/trunk, so this changeset will
          be null-merged.
        ------------------------------------------------------------
        revno: 2555.936.63
        committer: Inaam Rana <inaam.rana@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2011-11-18 10:59:10 -0500
        message:
          Bug#13390506 - VALGRIND FAILURE AFTER THE FIX FOR 13371000
            
          rb://816
          approved by: Marko Makela
            
          The title is misleading. This bug was actually introduced by
          bug 12635227 and was unearthed by a later optimization.
          We need to free buf_page_t structs that we are allocating using
          malloc() at shutdown.
        ------------------------------------------------------------
        revno: 2555.936.62
        committer: Jorgen Loland <jorgen.loland@oracle.com>
        branch nick: mysql-5.1
        timestamp: Fri 2011-11-18 14:47:11 +0100
        message:
          Backmerge of BUG#12997905
        ------------------------------------------------------------
        revno: 2555.936.61 [merge]
        committer: Karen Langford <karen.langford@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2011-11-17 00:26:16 +0100
        message:
          Merge from mysql-5.1.60-release
        ------------------------------------------------------------
        revno: 2555.936.60
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2011-11-10 16:45:47 +0200
        message:
          Bug #12842206 INNODB LOCKING REGRESSION FOR INSERT IGNORE: Add a test case.
          The bug was accidentally fixed by fixing
          Bug#11759688 52020: InnoDB can still deadlock on just INSERT...ON DUPLICATE KEY
          a.k.a. the reintroduction of
          Bug#7975 deadlock without any locking, simple select and update
        ------------------------------------------------------------
        revno: 2555.936.59
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2011-11-10 12:49:31 +0200
        message:
          Bug#11759688 52020: InnoDB can still deadlock on just INSERT...ON DUPLICATE KEY
          a.k.a. Bug#7975 deadlock without any locking, simple select and update
          
          Bug#7975 was reintroduced when the storage engine API was made
          pluggable in MySQL 5.1. Instead of looking at thd->lex directly, we
          rely on handler::extra(). But, we were looking at the wrong extra()
          flag, and we were ignoring the TRX_DUP_REPLACE flag in places where we
          should obey it.
          
          innodb_replace.test: Add tests for hopefully all affected statement
          types, so that bug should never ever resurface. This kind of tests
          should have been added when fixing Bug#7975 in MySQL 5.0.3 in the
          first place.
          
          rb:806 approved by Sunny Bains
        ------------------------------------------------------------
        revno: 2555.936.58
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Tue 2011-11-08 14:15:22 +0200
        message:
          Bug#13358468 ASSERTION FAILURE IN BTR_PCUR_GET_BLOCK
          
          btr_pcur_restore_position_func(): When the cursor was positioned at
          the tree infimum or supremum, initialize pos_state and latch_mode. The
          assertion failed, because pos_state was BTR_PCUR_WAS_POSITIONED.  In
          the test failure of WL#5874, the purge thread attempted to restore the
          cursor position on the infimum record (the clustered index was empty).
          
          btr_pcur_detach(), btr_pcur_is_detached(): Unused functions, remove.
          
          rb:804 approved by Inaam Rana
        ------------------------------------------------------------
        revno: 2555.936.57
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Mon 2011-11-07 13:37:19 +0200
        message:
          Add debug assertions to catch Bug#13345378 earlier.
          
          In all callers of row_sel_convert_mysql_key_to_innobase(), assert
          that the converted key is empty or nonempty when it should be.
    ------------------------------------------------------------
    revno: 2555.947.3 [merge]
    committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com>
    branch nick: merge-5.1-security
    timestamp: Fri 2011-11-04 14:33:38 +0200
    message:
      auto-merge mysql-5.1->mysql-5.5
        ------------------------------------------------------------
        revno: 2555.936.56
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1
        timestamp: Tue 2011-11-01 07:50:54 +0100
        message:
          Bug#12406055 post-push fix: unused variable 'num_chars' in optimized build.
          Also fixed possibly uninitialized use of need_copy_table_res.
        ------------------------------------------------------------
        revno: 2555.936.55
        committer: Tor Didriksen <tor.didriksen@oracle.com>
        branch nick: 5.1
        timestamp: Mon 2011-10-31 10:10:04 +0100
        message:
          Bug#12406055 post-push fix: unused variable 'num_chars' in optimized build.
        ------------------------------------------------------------
        revno: 2555.936.54
        committer: Marko M?kel? <marko.makela@oracle.com>
        branch nick: mysql-5.1
        timestamp: Thu 2011-10-27 14:58:12 +0300
        message:
          Bug #12884631 62146: TABLES ARE LOST FOR DDL
          
          row_rename_table_for_mysql(): Return DB_ERROR instead of DB_SUCCESS
          when fil_rename_tablespace() returns an error. This bug was introduced
          in the InnoDB Plugin.
          
          Approved by Sunny Bains over IM.
    ------------------------------------------------------------
    revno: 2555.947.2 [merge]
    committer: Alexander Nozdrin <alexander.nozdrin@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Thu 2011-10-27 10:22:19 +0400
    message:
      Empty merge from mysql-5.1.
        ------------------------------------------------------------
        revno: 2555.936.53
        committer: Karen Langford <karen.langford@oracle.com>
        branch nick: mysql-5.1
        timestamp: Wed 2011-10-26 20:48:42 +0200
        message:
          Increased version number after cloning 5.1.60
    ------------------------------------------------------------
    revno: 2555.947.1
    committer: Karen Langford <karen.langford@oracle.com>
    branch nick: mysql-5.1-security
    timestamp: Wed 2011-10-26 17:03:53 +0200
    message:
      Raise version number after cloning 5.1.60
