1. 25 Feb, 2011 1 commit
  2. 24 Feb, 2011 7 commits
  3. 23 Feb, 2011 8 commits
  4. 22 Feb, 2011 7 commits
    • hery.ramilison@oracle.com's avatar
      40b27a95
    • Sunny Bains's avatar
      Add ut0bh.ic. · 165ccf3b
      Sunny Bains authored
      165ccf3b
    • Sunny Bains's avatar
      Remove ut0bh.ic from 5.5 and then re-add so that the file ids are the same · 2cc16434
      Sunny Bains authored
      in 5.5 and trunk. First we remove the file in the commit.
      2cc16434
    • Nirbhay Choubey's avatar
      Merging from mysql-5.1. · a557cf13
      Nirbhay Choubey authored
      a557cf13
    • Nirbhay Choubey's avatar
      dd4723d4
    • Sunny Bains's avatar
      83659a7f
    • Sunny Bains's avatar
      Bug #11766227: InnoDB purge lag much worse for 5.5.8 versus 5.1 · 9d6d1902
      Sunny Bains authored
      Bug #11766501: Multiple RBS break the get rseg with mininum trx_t::no code during purge
            
      Bug# 59291 changes:
            
      Main problem is that truncating the UNDO log at the completion of every
      trx_purge() call is expensive as the number of rollback segments is increased.
      We truncate after a configurable amount of pages. The innodb_purge_batch_size
      parameter is used to control when InnoDB does the actual truncate. The truncate
      is done once after 128 (or TRX_SYS_N_RSEGS iterations). In other words we
      truncate after purge 128 * innodb_purge_batch_size. The smaller the batch
      size the quicker we truncate.
            
      Introduce a new parameter that allows how many rollback segments to use for
      storing REDO information. This is really step 1 in allowing complete control
      to the user over rollback space management.
            
      New parameters:
          i) innodb_rollback_segments = number of rollback_segments to use
             (default is now 128) dynamic parameter, can be changed anytime.
             Currently there is little benefit in changing it from the default.
            
      Optimisations in the patch.
            
          i. Change the O(n) behaviour of trx_rseg_get_on_id() to O(log n)
             Backported from 5.6. Refactor some of the binary heap code.
             Create a new include/ut0bh.ic file.
            
          ii. Avoid truncating the rollback segments after every purge.
            
      Related changes that were moved to a separate patch:
            
          i. Purge should not do any flushing, only wait for space to be free so that
             it only does purging of records unless it is held up by a long running
             transaction that is preventing it from progressing.
            
         ii. Give the purge thread preference over transactions when acquiring the
             rseg->mutex during commit. This to avoid purge blocking unnecessarily
             when getting the next rollback segment to purge.
            
      Bug #11766501 changes:
            
      Add the rseg to the min binary heap under the cover of the kernel mutex and
      the binary heap mutex. This ensures the ordering of the min binary heap.
            
      The two changes have to be committed together because they share the same
      that fixes both issues.
            
      rb://567 Approved by: Inaam Rana.
      9d6d1902
  5. 21 Feb, 2011 8 commits
    • Jorgen Loland's avatar
      BUG#11762751: UPDATE STATEMENT THROWS AN ERROR, BUT STILL · 44b41979
      Jorgen Loland authored
                    UPDATES THE TABLE ENTRIES (formerly 55385)
      BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND 
                    IF A TABLE IS UPDATED TWICE (formerly 57373)
                  
      If multiple-table update updates a row through two aliases and
      the first update physically moves the row, the second update will
      fail to locate the row. This results in different errors
      depending on storage engine:
        * MyISAM: Got error 134 from storage engine
        * InnoDB: Can't find record in 'tbl'
      None of these errors accurately describe the problem. 
            
      Furthermore, since MyISAM is non-transactional, the update
      executed first will be performed while the second will not.
      In addition, for two equal multiple-table update statements,
      one could succeed and the other fail based on whether or not
      the record actually moved or not. This was inconsistent.
            
      Two update operations may physically move a row:
        1) Update of a column in a clustered primary key
        2) Update of a column used to calculate which partition the 
           row belongs to
                 
      BUG#11764529 is about case 1) above, BUG#11762751 was about case 2).
            
      The fix for these bugs is to return with an error if multiple-table 
      update is about to:
        a) Update a table through multiple aliases, and
        b) Perform an update that may physically more the row 
           in at least one of these aliases
          
      This avoids 
        * partial updates as described for MyISAM above,
        * provides the same error message that describes the actual problem
          for all SEs
        * inconsistent behavior where a statement fails or succeeds based on
          e.g. the partitioning algorithm of the table.
      44b41979
    • Bjorn Munch's avatar
      Bug #11766640 (59789) Hook the invocation of unit tests in MTR. · 562978e1
      Bjorn Munch authored
      Added code to call 'ctest' if the needed cmake file is present
      Will do so unless tests/suited named on mtr command line
      Also add option to turn on/off
      Will be made to look like a test 'unit-test' which counts towards total
      Extracts summary report and any test failures from ctest output
      Addendum: added override to turn off in PB, add back in selected invocations
      562978e1
    • Magnus Blåudd's avatar
      Merge · c9601845
      Magnus Blåudd authored
      c9601845
    • Jon Olav Hauglid's avatar
      Bug #11754461 CANNOT ALTER TABLE WHEN KEY PREFIX TOO LONG · 5d42003f
      Jon Olav Hauglid authored
      The problem was that doing ALTER TABLE on a table which had a key
      on a TEXT/BLOB column with a prefix longer than the maximum number
      of characteres in this column (as per the character set), by mistake,
      caused an error (Error 1170 - ER_BLOB_KEY_WITHOUT_LENGTH).
      
      This bug not repeatable in 5.5.
      
      This patch adds a regression test to alter_table.test and
      contains no code changes.
      5d42003f
    • Magnus Blåudd's avatar
      Remove last traces of HAVE_NDBCLUSTER_DB define - it has not had an effect in... · 6ae9c150
      Magnus Blåudd authored
      Remove last traces of HAVE_NDBCLUSTER_DB define - it has not had an effect in a long time and is just confusing.
      At the same time backport the removal of OPT_NDB_CONNECTSTRING and OPT_NDBCLUSTER values from "enum options_client"
      6ae9c150
    • Sergey Vojtovich's avatar
      Merge. · 549f63ab
      Sergey Vojtovich authored
      549f63ab
    • Nirbhay Choubey's avatar
    • Nirbhay Choubey's avatar
      Bug#11766310 : 59398: MYSQLDUMP 5.1 CAN'T HANDLE A DASH · a8e6f7c6
      Nirbhay Choubey authored
                     ("-") IN DATABASE NAMES IN ALTER DATABASE.
      
      mysqldump did not quote database name in 'ALTER DATABASE'
      statements in its output. This can further cause a failure
      while loading if database name contains a hyphen '-'.
      
      This happened as, while printing the 'ALTER DATABASE'
      statements, the database name was not quoted.
      
      Fixed by quoting the database name.
      a8e6f7c6
  6. 18 Feb, 2011 9 commits