1. 03 Jul, 2009 11 commits
    • Alexey Kopytov's avatar
      Automerge. · cfebaf44
      Alexey Kopytov authored
      cfebaf44
    • Alexey Kopytov's avatar
      Manual merge. · 2d4df13e
      Alexey Kopytov authored
      2d4df13e
    • Sergey Glukhov's avatar
      5.0-bugteam->5.1-bugteam merge · 59d239e1
      Sergey Glukhov authored
      59d239e1
    • Sergey Glukhov's avatar
      Bug#45806 crash when replacing into a view with a join! · 2dd70946
      Sergey Glukhov authored
      The crash happend because for views which are joins
      we have table_list->table == 0 and 
      table_list->table->'any method' call leads to crash.
      The fix is to perform table_list->table->file->extra()
      method for all tables belonging to view.
      
      
      mysql-test/r/view.result:
        test result
      mysql-test/t/view.test:
        test case
      sql/sql_insert.cc:
        added prepare_for_positional_update() function
        which updates extra info about primary key for
        tables belonging to view.
      2dd70946
    • Bernt M. Johnsen's avatar
      Prepare for push · 15b23550
      Bernt M. Johnsen authored
      15b23550
    • Sergey Glukhov's avatar
      Bug#42364 SHOW ERRORS returns empty resultset after dropping non existent table · 45d59063
      Sergey Glukhov authored
      enabled message storing into error message list
      for 'drop table' command
      
      
      mysql-test/r/warnings.result:
        test result
      mysql-test/t/warnings.test:
        test case
      sql/sql_table.cc:
        We should skip error sending then we should return
        warnings to client as some functions may send its
        own errors, so we should set no_warnings_for_error= 0
        only in case of warning.
        The fix is to enable message storing into error message
        list for 'drop table' command(only for error case).
      tests/mysql_client_test.c:
        test fix
      45d59063
    • Bernt M. Johnsen's avatar
      automerge · 61488d2a
      Bernt M. Johnsen authored
      61488d2a
    • Bernt M. Johnsen's avatar
      Prepare for push · 768f5b08
      Bernt M. Johnsen authored
      768f5b08
    • Bernt M. Johnsen's avatar
      Bug#15866 Prepared for push on 5.1 · 7bb5986d
      Bernt M. Johnsen authored
      7bb5986d
    • Bernt M. Johnsen's avatar
      Bug#15866 Prepared for push on 5.0 · e0a3403b
      Bernt M. Johnsen authored
      e0a3403b
    • Alexey Kopytov's avatar
      Bug #45262: Bad effects with CREATE TABLE and DECIMAL · 096c12b2
      Alexey Kopytov authored
       
      Using DECIMAL constants with more than 65 digits in CREATE 
      TABLE ... SELECT led to bogus errors in release builds or 
      assertion failures in debug builds. 
       
      The problem was in inconsistency in how DECIMAL constants and 
      fields are handled internally. We allow arbitrarily long 
      DECIMAL constants, whereas DECIMAL(M,D) columns are limited to 
      M<=65 and D<=30. my_decimal_precision_to_length() was used in 
      both Item and Field code and truncated precision to 
      DECIMAL_MAX_PRECISION when calculating value length without 
      adjusting precision and decimals. As a result, a DECIMAL 
      constant with more than 65 digits ended up having length less 
      than precision or decimals which led to assertion failures. 
       
      Fixed by modifying my_decimal_precision_to_length() so that 
      precision is truncated to DECIMAL_MAX_PRECISION only for Field 
      object which is indicated by the new 'truncate' parameter. 
       
      Another inconsistency fixed by this patch is how DECIMAL 
      constants and expressions are handled for CREATE ... SELECT. 
      create_tmp_field_from_item() (which is used for constants) was 
      changed as a part of the bugfix for bug #24907 to handle long 
      DECIMAL constants gracefully. Item_func::tmp_table_field() 
      (which is used for expressions) on the other hand was still 
      using a simplistic approach when creating a Field_new_decimal 
      from a DECIMAL expression. 
      
      mysql-test/r/type_newdecimal.result:
        Added a test case for bug #45262.
      mysql-test/t/type_newdecimal.test:
        Added a test case for bug #45262.
      sql/item.cc:
        Use the new 'truncate' parameter in 
        my_decimal_precision_to_length().
      sql/item_cmpfunc.cc:
        Use the new 'truncate' parameter in 
        my_decimal_precision_to_length().
      sql/item_func.cc:
        1. Use the new 'truncate' parameter in 
        my_decimal_precision_to_length().
        
        2. Do not truncate decimal precision to DECIMAL_MAX_PRECISION
        for additive expressions involving long DECIMAL constants.
        
        3. Fixed an incosistency in how DECIMAL constants and 
        expressions are handled for CREATE ... SELECT.
      sql/item_func.h:
        Use the new 'truncate' parameter in 
        my_decimal_precision_to_length().
      sql/item_sum.cc:
        Use the new 'truncate' parameter in 
        my_decimal_precision_to_length().
      sql/my_decimal.h:
        Do not truncate precision to DECIMAL_MAX_PRECISION
        when calculating length in 
        my_decimal_precision_to_length() if 'truncate' parameter
        is FALSE.
      sql/sql_select.cc:
        1. Use the new 'truncate' parameter in 
        my_decimal_precision_to_length().
        
        2. Use a more correct logic when adjusting value's length.
      096c12b2
  2. 02 Jul, 2009 4 commits
    • Georgi Kodinov's avatar
      Bug #45807: crash accessing partitioned table and sql_mode · ae8950f1
      Georgi Kodinov authored
      contains ONLY_FULL_GROUP_BY
      
      The partitioning code needs to issue a Item::fix_fields()
      on the partitioning expression in order to prepare 
      it for being evaluated.
      It does this by creating a special table and a table list 
      for the scope of the partitioning expression.
      But when checking ONLY_FULL_GROUP_BY the 
      Item_field::fix_fields() was relying that there always be
      cached_table set and was trying to use it to get the 
      select_lex of the SELECT the field's table is in.
      But the cached_table was not set by the partitioning code
      that creates the artificial TABLE_LIST used to resolve the
      partitioning expression and this resulted in a crash.
       
      Fixed by rectifying the following errors :
      1. Item_field::fix_fields() : the code that check for 
      ONLY_FULL_GROUP_BY relies on having tables with 
      cacheable_table set. This is mostly true, the only 
      two exceptions being the partitioning context table
      and the trigger context table.
      Fixed by taking the current parsing context if no pointer
      to the TABLE_LIST instance is present in the cached_table.
      
      2. fix_fields_part_func() : 
      
      2a. The code that adds the table being created to the 
      scope for the partitioning expression is mostly a copy 
      of the add_table_to_list and friends with one exception :
      it was not marking the table as cacheable (something that
      normal add_table_to_list is doing). This caused the 
      problem in the check for ONLY_FULL_GROUP_BY in 
      Item_field::fix_fields() to appear.
      Fixed by setting the correct members to make the table
      cacheable.
      The ideal structural fix for this is to use a unified 
      interface for adding a table to a table list 
      (add_table_to_list?) : noted in a TODO comment
      
      2b. The Item::fix_fields() was called with a NULL destination
      pointer. This causes uninitalized memory reads in the 
      overloaded ::fix_fields() function (namely 
      Item_field::fix_fields()) as it expects a non-zero pointer 
      there. Fixed by passing the source pointer similarly to how 
      it's done in JOIN::prepare().
      
      mysql-test/r/partition.result:
        Bug #45807: test case
      mysql-test/t/partition.test:
        Bug #45807: test case
      sql/item.cc:
        Bug #45807: fix the ONLY_FULL_GROUP_BY check code to 
        handle correctly non-cacheable tables.
      sql/sql_partition.cc:
        Bug #45807: fix the Item::fix_fields() context
        initializatio for the partitioning expression in 
        CREATE TABLE.
      ae8950f1
    • Matthias Leich's avatar
      Merge 5.0 -> 5.1 of fix for bug 45902 · a01b9e29
      Matthias Leich authored
      a01b9e29
    • Matthias Leich's avatar
      Fix for Bug#45902 rpl_sp fails sporadically in check testcases · 3abee40e
      Matthias Leich authored
      Details:
      - Add "sync_slave_with_master" at test end
      - Restore the initial value of log_bin_trust_function_creators
      3abee40e
    • V Narayanan's avatar
      Bug#45793 macce charset causes error with IBMDB2I · fdf1461a
      V Narayanan authored
      Creating an IBMDB2I table with the macce character set
      is successful, but any attempt to insert data into the
      table was failing.
      
      This was happening because the character set name "macce"
      is not a valid iconv descriptor for IBM i PASE. This patch
      adds an override to convertTextDesc to use the equivalent
      valid iconv descriptor "IBM-1282" instead.
      
      mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45793.result:
        Bug#45793 macce charset causes error with IBMDB2I
        
        Result file for the test case.
      mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45793.test:
        Bug#45793 macce charset causes error with IBMDB2I
        
        Add a testcase for the macce charater set.
      storage/ibmdb2i/db2i_charsetSupport.cc:
        Bug#45793 macce charset causes error with IBMDB2I
        
        The character set name "macce" is not a valid iconv
        descriptor for IBM i PASE. Add an override to convertTextDesc
        to use the equivalent valid iconv descriptor "IBM-1282" 
        instead.
      fdf1461a
  3. 01 Jul, 2009 4 commits
    • Staale Smedseng's avatar
      Merge from 5.0 · 3c052dd0
      Staale Smedseng authored
      3c052dd0
    • Staale Smedseng's avatar
      Bug #45790 Potential DoS vector: Writing of user input to log · 3cd431d5
      Staale Smedseng authored
      without proper formatting
            
      The problem is that a suitably crafted database identifier
      supplied to COM_CREATE_DB or COM_DROP_DB can cause a SIGSEGV,
      and thereby a denial of service. The database name is printed
      to the log without using a format string, so potential
      attackers can control the behavior of my_b_vprintf() by
      supplying their own format string. A CREATE or DROP privilege
      would be required.
            
      This patch supplies a format string to the printing of the
      database name. A test case is added to mysql_client_test.
      
      
      sql/sql_parse.cc:
        Added format strings.
      tests/mysql_client_test.c:
        Added new test case.
      3cd431d5
    • Satya B's avatar
      merge to 5.1-bugteam · 95e2fd14
      Satya B authored
      95e2fd14
    • Satya B's avatar
      Fix build failure after applying Innodb snapshot 5.1-ss5282 · f903db67
      Satya B authored
      After applying Innodb snapshot 5.1-ss5282, build was broken
      because of missing header file. 
      
      Adding the header file to Makefile.am after informing the 
      innodb developers.
      f903db67
  4. 30 Jun, 2009 2 commits
  5. 29 Jun, 2009 10 commits
    • Staale Smedseng's avatar
      Merge from 5.0 · 300a8721
      Staale Smedseng authored
      300a8721
    • Staale Smedseng's avatar
      Merge from 5.0-bt · 67771508
      Staale Smedseng authored
      67771508
    • Satya B's avatar
      merge to mysql-5.1-bugteam branch · 477ada0a
      Satya B authored
      477ada0a
    • Satya B's avatar
      merge to mysql-5.1-bugteam · 889b96b9
      Satya B authored
      889b96b9
    • Christoffer Hall's avatar
      Merge from team tree · f383f648
      Christoffer Hall authored
      f383f648
    • Christoffer Hall's avatar
      Merge from main branch · 0d54c57c
      Christoffer Hall authored
      0d54c57c
    • Satya B's avatar
      183694ae
    • Satya B's avatar
      Additional Fix for BUG#40565 - Update Query Results in "1 Row Affected" · 729648c4
      Satya B authored
                                     But Should Be "Zero Rows"
      
      
      After applying the innodb snapshot 5.0-ss5406 for bug#40565, the windows push build
      tests failed because of the missing cast of void * pointer in row0sel.c file
      
      Informed the innodb developers and received patch by email.
      
      innobase/row/row0sel.c:
        Cast the default_rec which is a void * pointer
      729648c4
    • Luis Soares's avatar
      merge: 5.1-bt bug branch --> 5.1-bt latest · 40e87bcf
      Luis Soares authored
      40e87bcf
    • V Narayanan's avatar
      Bug#45196 Some collations do not sort correctly with IBMDB2I · db044ad9
      V Narayanan authored
      Some collations--including cp1250_czech_cs,latin2_czech_cs,
      ucs2/utf8_czech_ci, ucs2/utf8_danish_ci--are not being
      sorted correctly by the IBMDB2I storage engine. This
      was being caused because the sort order used by DB2 is
      incompatible with the order expected by MySQL.
      
      This patch removes support for the cp1250_czech_cs and
      latin2_czech_cs collations because it has been determined
      that the sort order used by DB2 is incompatible with the
      order expected by MySQL. Users needing a czech collation
      with IBMDB2I are encouraged to use a Unicode-based collation 
      instead of these single-byte collations. This patch also
      modifies the DB2 sort sequence used for ucs2/utf8_czech_ci
      and ucs2/utf8_danish_ci collations to better match the
      sorting expected by MySQL. This will only affect indexes
      or tables that are newly created through the IBMDB2I storage
      engine. Existing IBMDB2I tables will retain the old sort
      sequence until recreated.
      
      mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_45196.result:
        Bug#45196  Some collations do not sort correctly with IBMDB2I
        
        Result file for the test case.
      mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_45196.test:
        Bug#45196  Some collations do not sort correctly with IBMDB2I
        
        Adding tests for testing the sort order with the modified collations.
      storage/ibmdb2i/db2i_collationSupport.cc:
        Bug#45196  Some collations do not sort correctly with IBMDB2I
        
        Remove the support for the cp1250_czech_cs and latin2_czech_cs 
        collations because it has been determined that the sort order
        used by DB2 is incompatible with the order expected by MySQL.
        Users needing a czech collation with IBMDB2I are encouraged to
        use a Unicode-based collation instead of these single-byte
        collations. This patch also modifies the DB2 sort sequence
        used for ucs2/utf8_czech_ci and ucs2/utf8_danish_ci collations
        to better match the sorting expected by MySQL. This will only 
        affect indexes or tables that are newly created through the
        IBMDB2I storage engine. Existing IBMDB2I tables will retain
        the old sort sequence until recreated.
      db044ad9
  6. 27 Jun, 2009 1 commit
    • Luis Soares's avatar
      BUG#42851: Spurious "Statement is not safe to log in statement · 92956ef6
      Luis Soares authored
                 format." warnings
            
      Despite the fact that a statement would be filtered out from binlog, a
      warning would still be thrown if it was issued with the LIMIT.
            
      This patch addresses this issue by checking the filtering rules before
      printing out the warning.
      
      
      mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt:
        Parameter to filter out database: "b42851".
      mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test:
        Added a new test case.
      sql/sql_class.cc:
        Added filtering rules check to condition used to decide whether to
        printout warning or not.
      92956ef6
  7. 26 Jun, 2009 5 commits
    • Evgeny Potemkin's avatar
      Merged bug#45266. · f99df8f7
      Evgeny Potemkin authored
      f99df8f7
    • Evgeny Potemkin's avatar
      Bug#45266: Uninitialized variable lead to an empty result. · 93bac51e
      Evgeny Potemkin authored
      The TABLE::reginfo.impossible_range is used by the optimizer to indicate
      that the condition applied to the table is impossible. It wasn't initialized
      at table opening and this might lead to an empty result on complex queries:
      a query might set the impossible_range flag on a table and when the query finishes,
      all tables are returned back to the table cache. The next query that uses the table
      with the impossible_range flag set and an index over the table will see the flag
      and thus return an empty result.
      
      The open_table function now initializes the TABLE::reginfo.impossible_range
      variable.
      
      mysql-test/r/select.result:
        A test case for the bug#45266: Uninitialized variable lead to an empty result.
      mysql-test/t/select.test:
        A test case for the bug#45266: Uninitialized variable lead to an empty result.
      sql/sql_base.cc:
        Bug#45266: Uninitialized variable lead to an empty result.
        The open_table function now initializes the TABLE::reginfo.impossible_range
        variable.
      sql/sql_select.cc:
        Bug#45266: Uninitialized variable lead to an empty result.
        The open_table function now initializes the TABLE::reginfo.impossible_range
        variable.
      sql/structs.h:
        Bug#45266: Uninitialized variable lead to an empty result.
        A comment is added.
      93bac51e
    • Alexey Kopytov's avatar
      Automerge. · 498614a0
      Alexey Kopytov authored
      498614a0
    • Alexey Kopytov's avatar
      Automerge. · 59947ae6
      Alexey Kopytov authored
      59947ae6
    • Staale Smedseng's avatar
      Merge from 5.1-bugteam · 717a5c59
      Staale Smedseng authored
      717a5c59
  8. 25 Jun, 2009 3 commits
    • Luis Soares's avatar
      626d3e1d
    • Staale Smedseng's avatar
      Bug #34002 uninitialized Rows_examined for some admin queries · b828da99
      Staale Smedseng authored
      such as quit and shutdown
      
      Logging to slow log can produce an undetermined value for
      Rows_examined in special cases. In debug mode this manifests
      itself as any of the various marker values used to mark
      uninitialized memory on various platforms.
      
      If logging happens on a THD object that hasn't performed any
      row reads (on this or any previous connections), the
      THD::examined_row_count may be uninitialized. This patch adds
      initialization for this attribute.
      
      No automated test cases are added, as for this to be
      meaningful, we need to ensure that we're using a THD
      fulfilling the above conditions. This is hard to do in the
      mysql-test-run framework. The patch has been verified
      manually, however, by restarting mysqld and running the test
      included with the bug report.
      b828da99
    • Davi Arnaut's avatar
      Bug#45548: XA transaction without access to InnoDB tables crashes the server · eefdd70a
      Davi Arnaut authored
      The problem is that the one phase commit function failed to
      properly end a empty transaction. The solution is to ensure
      that the transaction cleanup procedure is invoked even for
      empty transactions.
      
      mysql-test/r/xa.result:
        Add test case result for Bug#45548
      mysql-test/t/xa.test:
        Add test case for Bug#45548
      sql/handler.cc:
        Invoke transaction cleanup function whenever a transaction is ended.
      eefdd70a