1. 12 Feb, 2008 1 commit
  2. 11 Feb, 2008 1 commit
  3. 10 Feb, 2008 4 commits
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-5.0-opt · 4c995786
      unknown authored
      into  mysql.com:/home/hf/work/33796/my50-33796
      
      4c995786
    • unknown's avatar
      Merge mysql.com:/home/hf/work/33796/my41-33796 · 381bfc8a
      unknown authored
      into  mysql.com:/home/hf/work/33796/my50-33796
      
      
      libmysql/libmysql.c:
        merging
      libmysqld/lib_sql.cc:
        merging
      381bfc8a
    • unknown's avatar
      Bug #33796 Memory leak for prepared statements in embedded server. · 075e0220
      unknown authored
      Field data for a query was stored to the stmt->alloc that is emptied
      with mysql_stmt_close statement only. That means a lot of memory can
      be occupied without a reason if used doesn't call mysql_stmt_close often.
      
      
      libmysql/libmysql.c:
        Bug #33796 Memory leak for prepared statements in embedded server.
        
        Clean up result->alloc even if there's no 'data' created
      libmysqld/lib_sql.cc:
        Bug #33796 Memory leak for prepared statements in embedded server.
        
        alloc 'fields' in the 'result.alloc' as the 'mem_root' is only cleaned with
        mysql_stmt_close'
      075e0220
    • unknown's avatar
      Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 8bcb5973
      unknown authored
      into  mysql.com:/home/tnurnberg/21567/50-21567
      
      
      sql/mysqld.cc:
        Auto merged
      8bcb5973
  4. 08 Feb, 2008 3 commits
    • unknown's avatar
      Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · a14095af
      unknown authored
      into  host.loc:/home/uchum/work/5.0-opt
      
      a14095af
    • unknown's avatar
      Fixed bug#15409: Columns with 64-element SET may not be updated with integers. · 1dbe6997
      unknown authored
      SET column storing procedure has been modified to be 64bit-clean.
      
      
      mysql-test/r/type_set.result:
        Added test case for bug#15409.
      mysql-test/t/type_set.test:
        Added test case for bug#15409.
      sql/field.cc:
        Fixed bug#15409.
        The Field_set::store(longlong nr,...) method incompletely
        calculates a bit mask for the comparison with a given number:
        if that number is greater than 0x7F00 0000 0000 0000 (LONGLONG_MAX),
        it uses zero bit mask instead of 0xFFFF FFFF FFFF FFFF (ULONGLONG_MAX).
        
        Incomplete expression has been replaced with a set_bits macro call.
      1dbe6997
    • unknown's avatar
      Bug#31590: Wrong error message on sort buffer being too small. · 2c468127
      unknown authored
      The out of memory error was thrown when the sort buffer size were too small.
      This led to a user confusion.
      
      Now filesort throws the error message about sort buffer being too small.
      
      
      mysql-test/t/order_by.test:
        Added a test case for the bug#31590: Wrong error message on sort buffer being too small.
      mysql-test/r/order_by.result:
        Added a test case for the bug#31590: Wrong error message on sort buffer being too small.
      sql/filesort.cc:
        Bug#31590: Wrong error message on sort buffer being too small.
        Now filesort throws the error message about sort buffer being too small
        instead of out of memory error.
      2c468127
  5. 07 Feb, 2008 7 commits
    • unknown's avatar
      Merge spetrunia@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · ec139476
      unknown authored
      into  mysql.com:/home/psergey/mysql-5.0-bug27732
      
      ec139476
    • unknown's avatar
      Merge host.loc:/home/uchum/work/5.0-opt-34223 · 27db386d
      unknown authored
      into  host.loc:/home/uchum/work/5.0-opt
      
      27db386d
    • unknown's avatar
      innodb_mysql.test, variables.result, variables.test, innodb_mysql.result: · 9c4bbbe2
      unknown authored
        Minor post-fix for bug#34223.
      
      
      mysql-test/r/innodb_mysql.result:
        Minor post-fix for bug#34223.
      mysql-test/r/variables.result:
        Minor post-fix for bug#34223.
      mysql-test/t/innodb_mysql.test:
        Minor post-fix for bug#34223.
      mysql-test/t/variables.test:
        Minor post-fix for bug#34223.
      9c4bbbe2
    • unknown's avatar
      BUG#27732 "Possible memory leak with index_merge" · 82f24597
      unknown authored
      The bug was that handler::clone/handler::ha_open() call caused allocation of 
      cloned_copy->ref on the handler->table->mem_root. The allocated memory could not 
      be reclaimed until the table is flushed, so it was possible to exhaust memory by 
      repeatedly running index_merge queries without doing table flushes.  
      
      The fix:
      - make handler::clone() allocate new_handler->ref on the passed mem_root 
      - make handler::ha_open() not allocate this->ref if it has already been allocated
      There is no testcase as it is not possible to check small leaks from testsuite.
      
      
      sql/handler.cc:
        BUG#27732 "Possible memory leak with index_merge"
        - make handler::clone() allocate new_handler->ref on the passed mem_root 
        - make handler::ha_open() not allocate this->ref if it has already been allocated
      82f24597
    • unknown's avatar
      Merge host.loc:/home/uchum/work/5.0-opt-34223 · 95fc3a4c
      unknown authored
      into  host.loc:/home/uchum/work/5.0-opt
      
      95fc3a4c
    • unknown's avatar
      bdb.result: · 4fa75443
      unknown authored
        Minor post-fix for bug#30059.
      
      
      mysql-test/r/bdb.result:
        Minor post-fix for bug#30059.
      4fa75443
    • unknown's avatar
      Fixed bug#34223: Failure on assignment to my_innodb_autoextend_increment · 6023a58e
      unknown authored
      and my_innodb_commit_concurrency global variables.
      
      Type of the my_innodb_autoextend_increment and the
      my_innodb_commit_concurrency variables has been changed to
      GET_ULONG.
      
      
      
      mysql-test/r/variables.result:
        Added test case for bug#34223.
      mysql-test/t/variables.test:
        Added test case for bug#34223.
      sql/mysqld.cc:
        Fixed bug#34223.
        Last update of the getopt_ull_limit_value function introduced
        a sanity check for a variable type (only GET_UINT or GET_ULONG
        are valid types).
        However, my_innodb_autoextend_increment and
        my_innodb_commit_concurrency are declared as GET_LONG.
        Call stack is: 
                sys_var_long_ptr_global::update()
                fix_unsigned()
                getopt_ull_limit_value()
        
        Type of the my_innodb_autoextend_increment and the
        my_innodb_commit_concurrency variables has been changed to
        GET_ULONG.
      6023a58e
  6. 06 Feb, 2008 1 commit
    • unknown's avatar
      Fixed bug#30059. · f54528b9
      unknown authored
      Server handles truncation for assignment of too-long values
      into CHAR/VARCHAR/TEXT columns in a different ways when the
      truncated characters are spaces:
      1. CHAR(N) columns silently ignore end-space truncation;
      2. TEXT columns post a truncation warning/error in the
         non-strict/strict mode.
      3. VARCHAR columns always post a truncation note in
         any mode.
      
      Space truncation processing has been synchronised over
      CHAR/VARCHAR/TEXT columns: current behavior of VARCHAR
      columns has been propagated as standard.
      
      Binary-encoded string/BLOB columns are not affected.
      
      
      mysql-test/r/heap.result:
        Updated test case for bug#30059.
      mysql-test/r/innodb.result:
        Updated test case for bug#30059.
      mysql-test/r/myisam.result:
        Updated test case for bug#30059.
      mysql-test/r/strict.result:
        Updated test case for bug#30059.
      mysql-test/r/type_binary.result:
        Updated test case for bug#30059.
      mysql-test/r/warnings.result:
        Added test case for bug#30059.
      mysql-test/t/warnings.test:
        Added test case for bug#30059.
      sql/field.cc:
        Fixed bug#30059.
        The report_data_too_long function was replaced with the
        Field_longstr::report_if_important_data method.
        
        The Field_string::store and the Field_blob::store
        methods was synchronized with the Field_varstring::store
        method.
        Changes:
        1. to CHAR(N): posting of space truncation note has been added
           in both (strict and non-strict) modes;
        2. to BLOBs: a check for space truncation has been added,
           a warning in the non-strict mode and an error message in
           the strict mode have been replaced with a truncation note.
        
        Similar parts of Field_string::store, Field_blob::store and
        Field_varstring::store have been moved to the
        Field_longstr::report_if_important_data method.
      sql/field.h:
        Fixed bug#30059.
        The Field_longstr::report_if_important_data method has been declared.
      f54528b9
  7. 05 Feb, 2008 1 commit
  8. 01 Feb, 2008 2 commits
    • unknown's avatar
      Merge mbp.local:/Users/kaa/src/opt/bug25162/my50-bug25162 · 1092649d
      unknown authored
      into  mbp.local:/Users/kaa/src/opt/mysql-5.0-opt
      
      1092649d
    • unknown's avatar
      Fix for bug #25162: Backing up DB from 5.1 adds 'USING BTREE' to KEYs · 653ab4ee
      unknown authored
                          on table creates
      
      The problem was in incompatible syntax for key definition in CREATE
      TABLE.
      
      5.0 supports only the following syntax for key definition (see "CREATE
      TABLE syntax" in the manual):
      
      {INDEX|KEY} [index_name] [index_type] (index_col_name,...)
      
      While 5.1 parser supports the above syntax, the "preferred" syntax was
      changed to:
      
      {INDEX|KEY} [index_name] (index_col_name,...) [index_type]
      
      The above syntax is used in 5.1 for the SHOW CREATE TABLE output, which
      led to dumps generated by 5.1 being incompatible with 5.0.
      
      Fixed by changing the parser in 5.0 to support both 5.0 and 5.1 syntax
      for key definition.
      
      
      mysql-test/r/create.result:
        Added a test case for bug #25162.
      mysql-test/t/create.test:
        Added a test case for bug #25162.
      sql/sql_yacc.yy:
        Changed the parser to support both 5.0 and 5.1 syntax for index type
        specification in CREATE TABLE.
      653ab4ee
  9. 31 Jan, 2008 1 commit
    • unknown's avatar
      Bug#30787: Stored function ignores user defined alias. · b46bc4a0
      unknown authored
      Simple subselects are pulled into upper selects. This operation substitutes the
      pulled subselect for the first item from the select list of the subselect.
      If an alias is defined for a subselect it is inherited by the replacement item.
      As this is done after fix_fields phase this alias isn't showed if the
      replacement item is a stored function. This happens because the Item_func_sp::make_field
      function makes send field from its result_field and ignores the defined alias.
      
      Now when an alias is defined the Item_func_sp::make_field function sets it for
      the returned field.
      
      
      mysql-test/t/sp.test:
        Added a test case for the bug#30787: Stored function ignores user defined alias.
      mysql-test/r/sp.result:
        Added a test case for the bug#30787: Stored function ignores user defined alias.
      sql/item_func.cc:
        Bug#30787: Stored function ignores user defined alias.
        Now when an alias is defined the Item_func_sp::make_field function sets it for
        the returned field.
      b46bc4a0
  10. 27 Jan, 2008 1 commit
    • unknown's avatar
      Fixed bug #33833. · 7dc4e4a5
      unknown authored
      Two disjuncts containing equalities of the form key=const1 and key=const2 can
      be merged into one if const1 is equal to const2. To check it the common 
      collation of the constants were used rather than the collation of the field key.
      For example when the default collation of the constants was cases insensitive
      while the collation of the field was case sensitive, then two or-ed equality 
      predicates key='b' and key='B' incorrectly were merged into one f='b'. As a 
      result ref access was used instead of range access and wrong result sets were 
      returned in many cases. 
      Fixed the problem by comparing constant in the or-ed predicate with collation of
      the key field.
      
      
      mysql-test/r/range.result:
        Added a test case for bug #33833.
      mysql-test/t/range.test:
        Added a test case for bug #33833.
      sql/item.cc:
        Fixed bug #33833.
        Added the method eq_by_collation that compares two items almost as 
        the method Item::eq, but it rather enforces a given collation for
        the comparison.
      sql/item.h:
        Fixed bug #33833.
        Added the method eq_by_collation that compares two items almost as 
        the method Item::eq, but it rather enforces a given collation for
        the comparison.
      7dc4e4a5
  11. 20 Jan, 2008 1 commit
  12. 18 Jan, 2008 2 commits
    • unknown's avatar
      Merge mhansson@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 5a82c60b
      unknown authored
      into  lamia.dupka:/home/mhansson/my50-bug33143-again-pushee
      
      5a82c60b
    • unknown's avatar
      BUG#33794 "MySQL crashes executing specific query": · c726f011
      unknown authored
      The problem occurred when one had a subquery that had an equality X=Y where 
      Y referred to a named select list expression from the parent select. MySQL 
      crashed when trying to use the X=Y equality for ref-based access. 
      
      Fixed by allowing non-Item_field items in the described case.
      
      
      mysql-test/r/subselect.result:
        BUG#33794 "MySQL crashes executing specific query"
        - Testcase
      mysql-test/t/subselect.test:
        BUG#33794 "MySQL crashes executing specific query"
        - Testcase
      sql/sql_select.cc:
        BUG#33794 "MySQL crashes executing specific query"
        get_store_key() assumed that if it got a reference
          t.key=Item_outer_ref(Item_direct_ref(x)) 
        then x was an Item_field object, which is not the case when one refers to a
        named select list expression out ot subquery.
      c726f011
  13. 17 Jan, 2008 1 commit
    • unknown's avatar
      Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt · b06eb2ec
      unknown authored
      into  linux-st28.site:/home/martin/mysql/src/bug33143/my50-bug33143-again-pushee
      
      
      sql/item_func.cc:
        Auto merged
      mysql-test/r/type_decimal.result:
        Bug#33143: Manual merge
      mysql-test/t/type_decimal.test:
        Bug#33143: Manual merge
      b06eb2ec
  14. 14 Jan, 2008 1 commit
    • unknown's avatar
      Bug#33143: Incorrect ORDER BY for ROUND()/TRUNCATE() result · 01557dde
      unknown authored
      The ROUND(X, D) function would change the Item::decimals field during
      execution to achieve the effect of a dynamic number of decimal digits.
      This caused a series of bugs:
      Bug #30617:Round() function not working under some circumstances in InnoDB
      Bug #33402:ROUND with decimal and non-constant cannot round to 0 decimal places
      Bug #30889:filesort and order by with float/numeric crashes server
      Fixed by never changing the number of shown digits for DECIMAL when
      used with a nonconstant number of decimal digits.
      
      
      mysql-test/r/type_decimal.result:
        Bug#33143: Test result
      mysql-test/t/type_decimal.test:
        Bug#33143: Test case
      sql/item_func.cc:
        Bug#33143: 
        - Moved the DECIMAL_MAX_SCALE limitation to fix_length_and_dec.
        - Removed resetting of Item::decimals field.
        - set the frac field of the output value to current scale.
      strings/decimal.c:
        Bug#33143: It is necessary to set all digits in the buffer following the 
        rounded one to zero, as they may now be displayed.
      01557dde
  15. 12 Jan, 2008 1 commit
  16. 11 Jan, 2008 3 commits
    • unknown's avatar
      Merge mhansson@bk-internal:/home/bk/mysql-5.0-opt · de17151f
      unknown authored
      into  linux-st28.site:/home/martin/mysql/src/bug31797/my50-bug31797-pushee
      
      
      sql/item.cc:
        Auto merged
      mysql-test/r/group_by.result:
        Bug#31797: Manual merge
      mysql-test/t/group_by.test:
        Bug#31797: Manual merge
      de17151f
    • unknown's avatar
      Bug#31797: error while parsing subqueries -- WHERE is parsed as HAVING · 2771cf8b
      unknown authored
      The name resolution for correlated subqueries and HAVING clauses
      failed to distinguish which of two was being performed when there 
      was a reference to an outer aliased field.
      Fixed by adding the condition that HAVING clause name resulotion
      is being performed.
      
      
      mysql-test/r/group_by.result:
        Bug#31797: Test result
      mysql-test/t/group_by.test:
        Bug#31797: Test case
      sql/item.cc:
        Bug#31797: 
        Corrected function comment.
        The fix, raising the error is restricted to HAVING name resolution.
      2771cf8b
    • unknown's avatar
      Bug#29477: Not all fields of the target table were checked to have a default · c328260a
      unknown authored
      value when inserting into a view.
      
      The mysql_prepare_insert function checks all fields of the target table that
      directly or indirectly (through a view) are specified in the INSERT
      statement to have a default value. This check can be skipped if the INSERT
      statement doesn't mention any insert fields. In case of a view this allows
      fields that aren't mentioned in the view to bypass the check.
      
      Now fields of the target table are always checked to have a default value
      when insert goes into a view.
      
      
      mysql-test/t/view.test:
        Added a test case for the bug#29477: Not all fields of the target table were 
        checked to have a default value when inserting into a view.
      mysql-test/r/view.result:
        Added a test case for the bug#29477: Not all fields of the target table were 
        checked to have a default value when inserting into a view.
      sql/sql_insert.cc:
        Bug#29477: Not all fields of the target table were checked to have a default
        value when inserting into a view.
        Now fields of the target table are always checked to have a default value
        when insert goes into a view.
      c328260a
  17. 10 Jan, 2008 5 commits
  18. 09 Jan, 2008 3 commits
  19. 08 Jan, 2008 1 commit
    • unknown's avatar
      Bug#33675: Usage of an uninitialized memory by filesort in a subquery caused · 89cccc7c
      unknown authored
      server crash.
      
      The filesort implementation has an optimization for subquery execution which
      consists of reusing previously allocated buffers. In particular the call to
      the read_buffpek_from_file function might be skipped when a big enough buffer
      for buffer descriptors (buffpeks) is already allocated. Beside allocating
      memory for buffpeks this function fills allocated buffer with data read from
      disk. Skipping it might led to using an arbitrary memory as fields' data and
      finally to a crash.
      
      Now the read_buffpek_from_file function is always called. It allocates
      new buffer only when necessary, but always fill it with correct data.
      
      
      sql/filesort.cc:
        Bug#33675: Usage of an uninitialized memory by filesort in a subquery caused
        server crash.Now the read_buffpek_from_file function is always called. It allocates
        new buffer only when necessary, but always fill it with correct data.
      mysql-test/r/subselect.result:
        Added a test case for the bug#33675: Usage of an uninitialized memory by
        filesort in a subquery caused server crash.
      mysql-test/t/subselect.test:
        Added a test case for the bug#33675: Usage of an uninitialized memory by
        filesort in a subquery caused server crash.
      89cccc7c