1. 08 Mar, 2011 1 commit
  2. 07 Mar, 2011 1 commit
    • unknown's avatar
      Bug#60196 / Bug#11831040 · 3df57153
      unknown authored
      Setting lowercase_table_names to 2 on Windows causing Foreign Key problems
      
      This problem was exposed by the fix for Bug#55222.  There was a codepath in dict0load.c,
      dict_load_foreigns() that made sure the table name matched case sensitive in order to
      load a referenced table into the dictionary as needed.  If an engine is rebooted which
      accesses a table with foreign keys, and lower_case_table_names=2, then the table with
      foreign keys will get an error when it is changed (insert/updated/delete).
      Once the referenced tables are loaded into the dictionary cache by a select statement
      on those tables, the same change would succeed because the affected code path would
      not get followed.
      3df57153
  3. 02 Mar, 2011 3 commits
  4. 01 Mar, 2011 8 commits
    • Vinay Fisrekar's avatar
      merge from mysql-5.1 -> mysql-5.5 · 09c5f5b7
      Vinay Fisrekar authored
      09c5f5b7
    • Vinay Fisrekar's avatar
      Bug#11766165 - 59211: SELECT RETURNS DIFFERENT VALUE FOR MIN(YEAR) FUNCTION · 758e4bfc
      Vinay Fisrekar authored
      Result File Correction For Bug Fix
      758e4bfc
    • Alexander Barkov's avatar
      Merging from mysql-5.1 · 7eb1898c
      Alexander Barkov authored
      7eb1898c
    • Magne Mahre's avatar
      Post-push cleanup, for Bug#11763065 et al. · 0da82cf8
      Magne Mahre authored
      0da82cf8
    • Alexander Barkov's avatar
      Bug#11766725 (Bug#59901) EXTRACTVALUE STILL BROKEN AFTER FIX FOR BUG #44332 · e2cab2c5
      Alexander Barkov authored
      Problem: a byte behind the end of input string was read
      in case of a broken XML not having a quote or doublequote
      character closing a string value.
      
      Fix: changing condition not to read behind the end of input string
      
        @ mysql-test/r/xml.result
        @ mysql-test/t/xml.test
        Adding tests
      
        @ strings/xml.c
        When checking if the closing quote/doublequote was found,
        using p->cur[0] us unsafe, as p->cur can point to the byte after the value.
        Comparing p->cur to p->beg instead.
      e2cab2c5
    • Alexander Barkov's avatar
      Bug#11753363 (bug#44793) CHARACTER SETS: CASE CLAUSE, UCS2 OR UTF32, FAILURE · 8a6c3948
      Alexander Barkov authored
      Problem: in case of string CASE/WHEN arguments with different
      character sets, Item_func_case::find_item() called comparator
      cmp_items[x] on mixed character set Items, so a 8-bit value could
      be errouneously referenced to as being utf16/utf32 value,
      which led to crash on DBUG_ASSERT() because of wrong value length.
      This was wrong, as string comparator expects arguments in the same
      character set.
      
      Fix: modify Item_func_case's argument list after calling
      agg_arg_charsets_for_comparison() - put the Items in "agg" array
      back to "args", because some of the Items in the "agg" array might
      have been changed to character set converters:
      - to Item_func_conv_charset for non-constant items
      - to Item_string for constant items
      
      In other words, perform the same substitution which is done in
      all other operations string comparison or string result operations:
      
      Replace
        CASE         latin1_item              WHEN utf16_item THEN ... END
      to
        CASE CONVERT(latin1_item USING utf16) WHEN utf16_item THEN ... END
      
      Replace
        CASE utf16_item WHEN         latin1_item              THEN ... END
      to
        CASE utf16_item WHEN CONVERT(latin1_item USING utf16) THEN ... END
      
      
        @ mysql-test/r/ctype_utf16.result
        @ mysql-test/r/ctype_utf32.result
        @ mysql-test/t/ctype_utf16.test
        @ mysql-test/t/ctype_utf32.test
        Adding tests
      
        @ sql/item_cmpfunc.cc
        Put "agg" back to "args".
      
        @ sql/sql_string.cc
        Backporting a fix for String::set_or_copy_aligned() from 5.6,
        for better test coverage:
        "SELECT _utf16 0x61" should expand the string to 0x0061 rather
        than to 0x000061.
        This fix was made in 5.6 under terms of "WL#4616 Implement UTF16-LE".
      8a6c3948
    • Magne Mahre's avatar
      Bug#11765237 - 58179: CANNOT START MYSQLD WITH APP VERIFIER · 236833bb
      Magne Mahre authored
      Bug#11763065 - 55730: KILL_SERVER() CALLS SETEVENT ON A NULL 
                     HANDLE, SMEM_EVENT_CONNECT_REQUEST
            
      Application Verifier is a Microsoft tool used for
      detecting certain classes of programming errors.
      In particular, MS Windows OS resource usage is
      monitored for wrong usage (handles, thread local
      storage, critical sections, ...)
            
      In MySQL 5.5.x, an error was introduced where an
      object on thread local storage was used before the
      TLS and the object was created.
            
      The fix has been to move the mysys initialization
      to an earlier stage in the boot process when built for
      Windows.  For non-win builds, the init already happens
      early.
      
      Some un-tangling of calls to my_init(), my_basic_init()
      and my_thread_global_init() was done.  There is no
      longer a need to do init in steps, so the full my_init()
      is called instead of my_init_basic().
            
      In addition,  Bug#11763065 was fixed.  The event handle
      'smem_event_connect_request' is only created if
      'opt_enable_shared_memory' is set.  When killing the
      server, an event was flagged on the handle
      unconditionally.  Added a test, so it will only be
      flagged if created.
      
      
      include/my_pthread.h:
        my_thread_basic_global_init is no longer
        necessary, and the my_thread_basic_global_reinit 
        function is renamed to reflect that it now
        reinits mutexes and condvars originating from
        my_thread_global_init
      mysys/my_thr_init.c:
        Reorganized code.
      236833bb
    • Dmitry Lenev's avatar
      Fix for bug #11765505 - "58480: LARGE_TESTS.LOCK_TABLES_BIG · 551c6ef4
      Dmitry Lenev authored
      IS FAILING".
      
      The problem was that large_tests.lock_tables_big test was
      failing due to exceeding open files limit on platforms where
      this limit was set too low (this test simultaneously opens
      approx. 6000 files).
      
      This patch solves this issue by ensuring that this test is
      skipped on such platforms.
      551c6ef4
  5. 28 Feb, 2011 5 commits
  6. 27 Feb, 2011 1 commit
  7. 25 Feb, 2011 4 commits
  8. 24 Feb, 2011 1 commit
  9. 23 Feb, 2011 6 commits
  10. 22 Feb, 2011 7 commits
    • unknown's avatar
      Null-merge from mysql-5.1.52sp1-release · 108b5937
      unknown authored
      108b5937
    • Sunny Bains's avatar
      Add ut0bh.ic. · 47e45a3e
      Sunny Bains authored
      47e45a3e
    • Sunny Bains's avatar
      Remove ut0bh.ic from 5.5 and then re-add so that the file ids are the same · 8342e3fd
      Sunny Bains authored
      in 5.5 and trunk. First we remove the file in the commit.
      8342e3fd
    • Nirbhay Choubey's avatar
      Merging from mysql-5.1. · ae59a024
      Nirbhay Choubey authored
      ae59a024
    • Nirbhay Choubey's avatar
      5a8efab2
    • Sunny Bains's avatar
      c4fbe417
    • Sunny Bains's avatar
      Bug #11766227: InnoDB purge lag much worse for 5.5.8 versus 5.1 · c27fc7d2
      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.
      c27fc7d2
  11. 21 Feb, 2011 3 commits
    • Jorgen Loland's avatar
      BUG#11762751: UPDATE STATEMENT THROWS AN ERROR, BUT STILL · 16c90215
      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.
      
      mysql-test/r/multi_update.result:
        Add test for bug#57373
      mysql-test/r/multi_update_innodb.result:
        Add test for bug#57373
      mysql-test/r/partition.result:
        Add test for bug#55385
      mysql-test/t/multi_update.test:
        Add test for bug#57373
      mysql-test/t/multi_update_innodb.test:
        Add test for bug#57373
      mysql-test/t/partition.test:
        Add test for bug#55385
      sql/handler.cc:
        Translate handler error HA_ERR_RECORD_DELETED to server error
      sql/share/errmsg-utf8.txt:
        New error message for multi-table update where the same table is updated multiple times.
      sql/sql_update.cc:
        Add function unsafe_key_update()
      16c90215
    • Magnus Blåudd's avatar
      Merge · a9472669
      Magnus Blåudd authored
      a9472669
    • Jon Olav Hauglid's avatar
      Bug #11754461 CANNOT ALTER TABLE WHEN KEY PREFIX TOO LONG · fe5dcec2
      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.
      fe5dcec2