1. 08 Mar, 2011 1 commit
    • Jon Olav Hauglid's avatar
      Bug #11755431 (former 47205) · 0db0e64f
      Jon Olav Hauglid authored
      MAP 'REPAIR TABLE' TO RECREATE +ANALYZE FOR ENGINES NOT
      SUPPORTING NATIVE REPAIR
      
      Executing 'mysqlcheck --check-upgrade --auto-repair ...' will first issue
      'CHECK TABLE FOR UPGRADE' for all tables in the database in order to check if the
      tables are compatible with the current version of MySQL. Any tables that are
      found incompatible are then upgraded using 'REPAIR TABLE'.
      
      The problem was that some engines (e.g. InnoDB) do not support 'REPAIR TABLE'.
      This caused any such tables to be left incompatible. As a result such tables were
      not properly fixed by the mysql_upgrade tool.
      
      This patch fixes the problem by first changing 'CHECK TABLE FOR UPGRADE' to return
      a different error message if the engine does not support REPAIR. Instead of
      "Table upgrade required. Please do "REPAIR TABLE ..." it will report
      "Table rebuild required. Please do "ALTER TABLE ... FORCE ..."
      
      Second, the patch changes mysqlcheck to do 'ALTER TABLE ... FORCE' instead of
      'REPAIR TABLE' in these cases.
      
      This patch also fixes 'ALTER TABLE ... FORCE' to actually rebuild the table.
      This change should be reflected in the documentation. Before this patch,
      'ALTER TABLE ... FORCE' was unused (See Bug#11746162)
      
      Test case added to mysqlcheck.test
      
      
      client/mysqlcheck.c:
        Changed mysqlcheck to do 'ALTER TABLE ... FORCE' if
        'CHECK TABLE FOR UPGRADE' reports ER_TABLE_NEEDS_REBUILD
        and not ER_TABLE_NEEDS_UPGRADE.
      mysql-test/r/mysqlcheck.result:
        Added regression test.
      mysql-test/std_data/bug47205.frm:
        InnoDB 5.0 FRM which contains a varchar primary key using
        utf8_general_ci. This is an incompatible FRM for 5.5.
      mysql-test/t/mysqlcheck.test:
        Added regression test.
      sql/handler.h:
        Added new HA_CAN_REPAIR flag.
      sql/share/errmsg-utf8.txt:
        Added new error message ER_TABLE_NEEDS_REBUILD
      sql/sql_admin.cc:
        Changed 'CHECK TABLE FOR UPDATE' to give ER_TABLE_NEEDS_REBUILD
        instead of ER_TABLE_NEEDS_UPGRADE if the engine does not support
        REPAIR (as indicated by the new HA_CAN_REPAIR flag).
      sql/sql_lex.h:
        Remove unused ALTER_FORCE flag.
      sql/sql_yacc.yy:
        Make sure ALTER TABLE ... FORCE recreates the table
        by setting the ALTER_RECREATE flag as the ALTER_FORCE
        flag was unused.
      storage/archive/ha_archive.h:
        Added new HA_CAN_REPAIR flag to Archive
      storage/csv/ha_tina.h:
        Added new HA_CAN_REPAIR flag to CSV
      storage/federated/ha_federated.h:
        Added new HA_CAN_REPAIR flag to Federated
      storage/myisam/ha_myisam.cc:
        Added new HA_CAN_REPAIR flag to MyISAM
      0db0e64f
  2. 07 Mar, 2011 2 commits
    • Jon Olav Hauglid's avatar
      Bug #11784056 ENABLE CONCURRENT READS WHILE CREATING · 5e32755e
      Jon Olav Hauglid authored
                    NON-PRIMARY UNIQUE INDEX USING INNODB
      
      This patch adds the HA_INPLACE_ADD_UNIQUE_INDEX_NO_WRITE
      capability flag to InnoDB, indicating that concurrent reads
      can be allowed while non-primary unique indexes are created.
      
      This is an follow-up to Bug #11751388 which enabled concurrent
      reads when creating non-primary non-unique indexes.
      
      Test case added to innodb_mysql_sync.test.
      5e32755e
    • Jon Olav Hauglid's avatar
      Bug #11764779 (former 57649) · bafe2403
      Jon Olav Hauglid authored
      FLUSH TABLES under FLUSH TABLES <list> WITH READ LOCK leads 
      to assert failure.
      
      This assert was triggered if a statement tried up upgrade a metadata
      lock with an active FLUSH TABLE <list> WITH READ LOCK. The assert 
      checks that the connection already holds a global intention exclusive
      metadata lock. However, FLUSH TABLE <list> WITH READ LOCK does not
      acquire this lock in order to be compatible with FLUSH TABLES WITH
      READ LOCK. Therefore any metadata lock upgrade caused the assert to
      be triggered.
      
      This patch fixes the problem by preventing metadata lock upgrade
      if the connection has an active FLUSH TABLE <list> WITH READ LOCK.
      ER_TABLE_NOT_LOCKED_FOR_WRITE will instead be reported to the client.
      
      Test case added to flush.test.
      bafe2403
  3. 04 Mar, 2011 3 commits
    • Alexander Barkov's avatar
      Bug#11764503 (Bug#57341) Query in EXPLAIN EXTENDED shows wrong characters · b326b9a3
      Alexander Barkov authored
        @ mysql-test/r/ctype_latin1.result
        @ mysql-test/r/ctype_utf8.result
        @ mysql-test/t/ctype_latin1.test
        @ mysql-test/t/ctype_utf8.test
        Adding tests
      
        @ sql/mysqld.h
        @ sql/item.cc
        @ sql/sql_parse.cc
        @ sql/sql_view.cc
      
        Refactoring (thanks to Guilhem for the idea):
      
        Item_string::print() was hard to understand because of the different
        QT_ constants: in "query_type==QT_x", QT_x is explicitely included
        but the other two QT_ are implicitely excluded. The combinations
        with '||' and '&&' make this even harder.
        - logic is now more "explicit" by changing QT_ constants to a bitmap of flags:
          QT_ORDINARY: no change,
          QT_IS -> QT_TO_SYSTEM_CHARSET | QT_WITHOUT_INTRODUCERS,
          QT_EXPLAIN -> QT_TO_SYSTEM_CHARSET
          (QT_EXPLAIN was introduced in the first version of the Bug#57341 patch)
        - Item_string::print() is rewritten using those flags
      
        Bugfix itself:
      
        When QT_TO_SYSTEM_CHARSET is used alone (with no QT_WITHOUT_INTRODUCERS),
        we print string literals as follows:
      
        - display introducers if they were in the original query
        - print ASCII characters as is
        - print non-ASCII characters using hex-escape
        Note: as "EXPLAIN" output is only for human readability purposes
        and does not need to be a pasrable SQL, so using hex-escape is Ok.
        ErrConvString class perfectly suites for hex escaping purposes.
      b326b9a3
    • Nirbhay Choubey's avatar
      BUG#11766219 : 59280: $MYSQL_HOME IS NOT USED FOR THE · 7e6d938f
      Nirbhay Choubey authored
                     CLIENT CONFIGURATION.
      
      At startup, MySQL server/client programs do not read
      configuration file pointed by MYSQL_HOME environment
      variable.
      
      This happened as, this environment variable was
      handled by a different variable (DEFAULT_HOME_ENV)
      in the code, which was ne'er initialized.
      
      Fixed by changing it to MYSQL_HOME.
      
      
      mysys/default.c:
        BUG 11766219 : 59280: $MYSQL_HOME IS NOT USED FOR THE
                       CLIENT CONFIGURATION.
        
        In the current build environment, the variable
        DEFAULT_HOME_ENV is no more found being initialized
        to MYSQL_HOME (as was the case earlier). Changed the
        variable name to MYSQL_HOME.
      7e6d938f
    • Jorgen Loland's avatar
      BUG#11766317: FIND_IN_SET won't work normaly after upgrade · 4015719c
      Jorgen Loland authored
                    from 5.1 to 5.5
      
      (Former 59405)
      
      In this bug, args[0] in an Item_func_find_in_set stored an 
      Item_func_weekday that was constant. In 
      Item_func_find_in_set::fix_length_and_dec(), args[0]->val_str() 
      was called. Later, when Item_func_find_in_set::val_int() was 
      called, args[0]->null_value was checked. However, the 
      Item_func_weekday in args[0] had now been replaced with an 
      Item_cache. No val_*() calls had been made to this Item_cache,
      thus null_value was incorrectly 'true', resulting in missing 
      rows in the result set.
      
      enum_value gets a value in fix_length_and_dec() iff args[0]
      is both constant and non-null. It is therefore unnecessary 
      to check the null_value of args[0] in val_int().
      
      An alternative fix would be to call args[0]->val_int() inside 
      Item_func_find_in_set::val_int(). This would ensure
      args[0]->null_value was set correctly (always false in this case), 
      but that would have to be done for every record this const value 
      is checked against.
      
      
      mysql-test/r/func_set.result:
        Add test for BUG#59405
      mysql-test/t/func_set.test:
        Add test for BUG#59405
      4015719c
  4. 03 Mar, 2011 9 commits
  5. 02 Mar, 2011 1 commit
  6. 01 Mar, 2011 8 commits
    • Vinay Fisrekar's avatar
      merge from mysql-5.1 -> mysql-5.5 · be386ebb
      Vinay Fisrekar authored
      be386ebb
    • Vinay Fisrekar's avatar
      Bug#11766165 - 59211: SELECT RETURNS DIFFERENT VALUE FOR MIN(YEAR) FUNCTION · 845e36e1
      Vinay Fisrekar authored
      Result File Correction For Bug Fix
      845e36e1
    • Alexander Barkov's avatar
      Merging from mysql-5.1 · 561738dc
      Alexander Barkov authored
      561738dc
    • Magne Mahre's avatar
      Post-push cleanup, for Bug#11763065 et al. · a4481d32
      Magne Mahre authored
      a4481d32
    • Alexander Barkov's avatar
      Bug#11766725 (Bug#59901) EXTRACTVALUE STILL BROKEN AFTER FIX FOR BUG #44332 · fd1e3b03
      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.
      fd1e3b03
    • Alexander Barkov's avatar
      Bug#11753363 (bug#44793) CHARACTER SETS: CASE CLAUSE, UCS2 OR UTF32, FAILURE · 14263b22
      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".
      14263b22
    • Magne Mahre's avatar
      Bug#11765237 - 58179: CANNOT START MYSQLD WITH APP VERIFIER · c4715a80
      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.
      c4715a80
    • Dmitry Lenev's avatar
      Fix for bug #11765505 - "58480: LARGE_TESTS.LOCK_TABLES_BIG · 901226b6
      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.
      901226b6
  7. 27 Feb, 2011 1 commit
  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 · fc6197ab
      unknown authored
      fc6197ab
    • Sunny Bains's avatar
      Add ut0bh.ic. · da66465a
      Sunny Bains authored
      da66465a
    • Sunny Bains's avatar
      Remove ut0bh.ic from 5.5 and then re-add so that the file ids are the same · cfcd6ead
      Sunny Bains authored
      in 5.5 and trunk. First we remove the file in the commit.
      cfcd6ead
    • Nirbhay Choubey's avatar
      Merging from mysql-5.1. · 07e30567
      Nirbhay Choubey authored
      07e30567
    • Nirbhay Choubey's avatar
      f27a13cf
    • Sunny Bains's avatar
      a5cd4872
    • Sunny Bains's avatar
      Bug #11766227: InnoDB purge lag much worse for 5.5.8 versus 5.1 · b3c9cc6f
      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.
      b3c9cc6f
  11. 21 Feb, 2011 1 commit
    • Jorgen Loland's avatar
      BUG#11762751: UPDATE STATEMENT THROWS AN ERROR, BUT STILL · d1d16687
      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()
      d1d16687