1. 15 Mar, 2011 2 commits
  2. 14 Mar, 2011 3 commits
    • Kristofer Pettersson's avatar
      automerge · 4f786b3e
      Kristofer Pettersson authored
      4f786b3e
    • Jorgen Loland's avatar
      BUG#11766234: ASSERT (TABLE_REF->TABLE || TABLE_REF->VIEW) · 4185869e
      Jorgen Loland authored
                    FAILS IN SET_FIELD_ITERATOR
      
      (Former 59299)
      
      When a PROCEDURE does a natural join, resolving of which columns are
      used in the join is done only once; consecutive CALLs to the procedure
      will reuse this information:
      
      CREATE PROCEDURE proc() SELECT * FROM t1 NATURAL JOIN v1;
      CALL proc();   <- natural join columns resolved here
      CALL proc();   <- reuse resolved NJ columns from first CALL
      
      The second CALL knows that it can reuse the resolved NJ columns because
      the first CALL sets st_select_lex::first_natural_join_processing=false.
      The problem in this bug was that the table the view v1 depends on 
      changed between CREATE PROCEDURE and the first CALL: 
      
      CREATE PROCEDURE...
      ALTER TABLE t2 CHANGE COLUMN a b CHAR;
      CALL proc();   <- error when resolving natural join columns
      CALL proc();   <- tries to reuse from first CALL => crash
      
      The fix for this bug is to set first_natural_join_processing= FALSE iff
      the natural join columns resolving was successful.
      
      
      mysql-test/r/sp.result:
        Add test for bug 11766234
      mysql-test/t/sp.test:
        Add test for bug 11766234
      sql/sql_base.cc:
        Set first_natural_join_processing= FALSE iff the natural join columns resolving was successful.
      4185869e
    • Kristofer Pettersson's avatar
      Certain fields in the protcol required a strict formatting. If · abd2e20b
      Kristofer Pettersson authored
      off bound values were sent to the server this could under some
      circumstances lead to a crash on the Windows platform.
      abd2e20b
  3. 11 Mar, 2011 3 commits
  4. 09 Mar, 2011 10 commits
  5. 08 Mar, 2011 2 commits
    • Marc Alff's avatar
      Bug#11830755 - UNIT TESTS PFS_INSTR AND PFS_INSTR_CLASS CRASH IN MUTEX CALLS ON WINDOWS · d1cbc64c
      Marc Alff authored
      Before this fix, two performance schema unit tests crashed on windows.
      
      The problem was a missing initialization to PFS_atomics,
      which caused the crash only for platform not compiled with native atomics.
      
      This fix adds the missing initialization in the unit tests.
      No production code was changed, this is a unit test bug only.
      d1cbc64c
    • 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
  6. 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
  7. 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
  8. 03 Mar, 2011 12 commits
  9. 02 Mar, 2011 1 commit
  10. 01 Mar, 2011 2 commits