1. 06 Jul, 2009 14 commits
  2. 03 Jul, 2009 13 commits
    • Kristofer Pettersson's avatar
      5.0-bugteam -> 5.1-bugteam · 1621a97f
      Kristofer Pettersson authored
      1621a97f
    • Kristofer Pettersson's avatar
      Bug#37274 client 'status' command doesn't print all info after losing connection to · 5899e13a
      Kristofer Pettersson authored
                server
      
      If the server connection was lost during repeated status commands,
      the client would fail to detect this and the client output would be inconsistent.
      
      This patch fixes this issue by making sure that the server is online
      before the client attempts to execute the status command.
      
      
      client/mysql.cc:
        * Replace variable "connected" with a call to mysql_real_query_for_lazy()
          will attempt to reconnect to server on if there is a failure.
      5899e13a
    • 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
  3. 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
  4. 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
  5. 30 Jun, 2009 2 commits
  6. 29 Jun, 2009 3 commits