1. 21 May, 2007 1 commit
  2. 18 May, 2007 7 commits
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-4.1 · 25090a6d
      unknown authored
      into  mysql.com:/d2/hf/mrg/mysql-4.1-opt
      
      
      25090a6d
    • unknown's avatar
      Merge perch.ndb.mysql.com:/home/jonas/src/41-work · c960adfe
      unknown authored
      into  perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
      
      
      c960adfe
    • unknown's avatar
      ndb - bug#28443 · deba58ee
      unknown authored
        review comment 2, atleast 1 signal need for test prg
      
      
      ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
        review comment, atleast 1 signal need
      deba58ee
    • unknown's avatar
      Merge perch.ndb.mysql.com:/home/jonas/src/41-work · 692c13ab
      unknown authored
      into  perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
      
      
      692c13ab
    • unknown's avatar
      ndb - bug#28443 · a5731933
      unknown authored
        review comment
        if some tcp-transporter has data, then do select with timeout 0
      
      
      ndb/src/common/transporter/TransporterRegistry.cpp:
        review comment
        if some tcp-transporter has data, then do select with timeout 0
      a5731933
    • unknown's avatar
      Merge perch.ndb.mysql.com:/home/jonas/src/41-work · b98be8f6
      unknown authored
      into  perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
      
      
      b98be8f6
    • unknown's avatar
      ndb - bug#28443 · 9bfed519
      unknown authored
        Make sure that data can not e left lingering in receive buffer
      
      
      ndb/src/common/transporter/Packer.cpp:
        test, make MAX_RECEIVED_SIGNALS an variable
      ndb/src/common/transporter/TCP_Transporter.hpp:
        add new method for checking of data in receive buffer
      ndb/src/common/transporter/TransporterRegistry.cpp:
        Make sure that 
        1) poll_TCP return true if any transporter has data in receiveBuffer
           (previously only if socket had data)
        2) performReceive executes signals if TCP transporter has data in receiveBuffer
           (previously only if data was recevied)
      ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
        test, make MAX_RECEIVED_SIGNALS an variable
      ndb/test/ndbapi/testNdbApi.cpp:
        testcase
      ndb/test/run-test/daily-basic-tests.txt:
        testcase
      9bfed519
  3. 16 May, 2007 1 commit
  4. 15 May, 2007 2 commits
    • unknown's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-4.1 · c3c64f1a
      unknown authored
      into  vajra.(none):/opt/local/work/mysql-4.1-runtime
      
      
      c3c64f1a
    • unknown's avatar
      Fixed bug #28272: crash that occurs when running an EXPLAIN command · 8762539d
      unknown authored
      for a query over an empty table right after its creation. 
      The crash is the result of an attempt made by JOIN::optimize to evaluate
      the WHERE condition when no records have been actually read.
      The added test case can reproduce the crash only with InnoDB tables and
      only with 5.0.x.
       
      
      
      mysql-test/r/innodb_mysql.result:
        Added a test case for bug #28272.
      mysql-test/t/innodb_mysql.test:
        Added a test case for bug #28272.
      sql/sql_select.cc:
        Fixed bug #28272: crash that occurs when running an EXPLAIN command
        for a query over an empty table right after its creation. 
        The crash is the result of an attempt made by JOIN::optimize to evaluate
        the WHERE condition when no records have been actually read.
        Such attempts could be observed only with EXPLAIN commands.
        Now at the optimization phase the WHERE condition is never evaluated if 
        there is no record previously read from the table.
      8762539d
  5. 14 May, 2007 2 commits
    • unknown's avatar
      Fixed bug #27937: crash for the the second execution of a prepared · fca58c95
      unknown authored
      statement from a UNION query with ORDER BY an expression containing
      RAND().
      The crash happened because the global order by list in the union query
      was not re-initialized for execution.
      (Local order by lists were re-initialized though).
      
      
      
      mysql-test/r/ps.result:
        Added a test case for bug #27937.
      mysql-test/t/ps.test:
        Added a test case for bug #27937.
      sql/sql_union.cc:
        Fixed bug #27937: crash for the the second execution of a prepared
        statement from a UNION query with ORDER BY an expression containing
        RAND().
        The crash happened because the global order by list in the union query
        was not re-initialized for execution.
        (Local order by lists were re-initialized though).
        Added re-initialization of the global order by list in the function
        st_select_lex_unit::init_prepare_fake_select_lex.
      fca58c95
    • unknown's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build · 4ce5e86f
      unknown authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work
      
      
      4ce5e86f
  6. 10 May, 2007 1 commit
  7. 08 May, 2007 2 commits
    • unknown's avatar
      Bug #27792 query cache returns wrong result, with certain system variables · ed947499
      unknown authored
       - Queries in the query cache are identified by the individual 
         characters in the query statement, the current database and 
         the current environment expressed as a set of system variable
         flags.
       - Since the set of environment flags didn't properly describe the
         current environment unexpected results were returned from the 
         query cache.
       - Query cache is now cleared when the variable ft_boolean_syntax is 
         updated.
       - An identification flag for the variable default_week_format is 
         added to the query cache record.
       
      Thanks to Martin Friebe who has supplied significant parts of this patch.
      
      
      mysql-test/r/query_cache.result:
        Added test case
      mysql-test/t/query_cache.test:
        Added test case
      sql/mysql_priv.h:
        - Added missing flags to reflect the significant local environment
          settings of the cached query.
      sql/set_var.cc:
        - Added query cache flush when system variable ft_boolean_syntax is
          updated since this also invalidates all cached result sets using this
          variable.
      sql/sql_cache.cc:
        - Added another local system variable as an identification flag
          for cached queries.
      ed947499
    • unknown's avatar
      Merge dev3-221.dev.cn.tlan:/home/ngb/mysql/mysql-4.1/mysql-4.1-ndb-bj · 6aa333d9
      unknown authored
      into  dev3-221.dev.cn.tlan:/home/ngb/mysql/mysql-4.1/mysql-4.1-ndb
      
      
      6aa333d9
  8. 07 May, 2007 1 commit
  9. 04 May, 2007 2 commits
    • unknown's avatar
      Bug #27531: the 4.1 fix. · 353b6f26
      unknown authored
      When checking for applicability of join cache
      we must disable its usage only if there is no
      temp table in use.
      When a temp table is used we can use join
      cache (and it will not make the result-set 
      unordered) to fill the temp table. The filesort() 
      operation is then applied to the data in the temp 
      table and hence is not affected by join cache
      usage.
      Fixed by narrowing the condition for disabling 
      join cache to exclude the case where temp table
      is used.
      
      
      mysql-test/r/join.result:
        Bug #27531: test case
      mysql-test/t/join.test:
        Bug #27531: test case
      sql/sql_select.cc:
        Bug #27531: 
        Disable join cache only if not using temp table
      353b6f26
    • unknown's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build · a196d66f
      unknown authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work
      
      
      a196d66f
  10. 03 May, 2007 1 commit
    • unknown's avatar
      Bug#23656: Wrong conversion result of a DATETIME to integer using CAST function. · 1a0e3a28
      unknown authored
      The generic string to int conversion was used by the Item_func_signed and
      the Item_func_unsigned classes to convert DATE/DATETIME values to the
      SIGNED/UNSIGNED type. But this conversion produces wrong results for such
      values.
      
      Now if the item which result has to be converted can return its result as
      longlong then the item->val_int() method is used to allow the item to carry
      out the conversion itself and return the correct result.
      This condition is checked in the Item_func_signed::val_int() and the
      Item_func_unsigned::val_int() functions.
      
      
      mysql-test/t/cast.test:
        Added a test case for the bug#23656: Wrong conversion result of a DATETIME to integer using CAST function.
      mysql-test/r/cast.result:
        Added a test case for the bug#23656: Wrong conversion result of a DATETIME to integer using CAST function.
      sql/item_func.cc:
        Bug#23656: Wrong conversion result of a DATETIME to integer using CAST function.
        Now if the item which result has to be converted can return its result as
        longlong then the item->val_int() method is used to allow the item to carry
        out the conversion itself and return the correct result.
        This condition is checked in the Item_func_signed::val_int() and the
        Item_func_unsigned::val_int() functions.
      1a0e3a28
  11. 02 May, 2007 2 commits
  12. 30 Apr, 2007 1 commit
  13. 29 Apr, 2007 5 commits
    • unknown's avatar
      Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack · dd34042e
      unknown authored
      some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
      list contained constant expressions.
      
      This happened because the results of constant expressions were not put
      in the temporary table used for duplicate elimination. In fact a constant
      item from the GROUP BY list of a ROLLUP query can be replaced for an
      Item_null_result object when a rollup row is produced . 
      
      Now the JOIN::rollup_init function wraps any constant item referenced in
      the GROYP BY list of a ROLLUP query into an Item_func object of a special
      class that is never detected as constant item. This ensures creation of
      fields for such  constant items in temporary tables and guarantees right
      results when the result of the rollup operation first has to be written
      into a temporary table, e.g. in the cases when duplicate elimination is
      required.  
      
      
      mysql-test/r/olap.result:
        Added a test case for bug #24856.
      mysql-test/t/olap.test:
        Added a test case for bug #24856.
      sql/item_func.h:
        Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack
        some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
        list contained constant expressions.
        
        Itroduced class Item_func_rollup_const derived from Item_func. The object of
        this class are never detected as constant items.
        We use them for wrapping constant items from the GROUP BY list of any ROLLUP
        query. This wrapping allows us to ensure writing constant items into temporary
        tables whenever the result of the ROLLUP operation has to be written into a
        temporary table, e.g. when ROLLUP is used together with DISTINCT in the SELECT
        list.
      sql/sql_select.cc:
        Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack
        some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
        list contained constant expressions.
        
        Now the JOIN::rollup_init function wraps any constant item referenced in
        the GROYP BY list of a ROLLUP query into an Item_func object of a special
        class that is never detected as constant item. This ensures creation of
        fields for such  constant items in temporary tables and guarantees right
        results when the result of the rollup operation first has to be written
        into a temporary table, e.g. in the cases when duplicate elimination is
        required.
      dd34042e
    • unknown's avatar
      Merge bk@192.168.21.1:mysql-4.1 · 0cd6377f
      unknown authored
      into  mysql.com:/d2/hf/mrg/mysql-4.1-opt
      
      
      0cd6377f
    • unknown's avatar
    • unknown's avatar
      Merge gshchepa.loc:/home/uchum/work/bk-trees/mysql-4.1-opt · 25033826
      unknown authored
      into  gshchepa.loc:/home/uchum/work/bk-trees/mysql-4.1-opt-13191
      
      
      25033826
    • unknown's avatar
      Adjusted results after the fix for bug #20710. · 3f169678
      unknown authored
      3f169678
  14. 28 Apr, 2007 3 commits
    • unknown's avatar
      Fixed bug #13191. · 98c0da4e
      unknown authored
      INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
      "Can't find record in ..." if we are inserting into
      InnoDB table unique index of partial key with
      underlying UTF-8 string field.
      
      This error occurs because INSERT...ON DUPLICATE uses a wrong
      procedure to copy string fields of multi-byte character sets
      for index search.
      
      
      mysql-test/t/innodb_mysql.test:
        Added test case for bug #13191.
      mysql-test/r/innodb_mysql.result:
        Added test case for bug #13191.
      sql/field.h:
        Fixed bug #13191.
        Field_string::get_key_image() virtual function was overloaded
        to implement copying of variable length character (UTF-8) fields.
        Field::get_key_image() function prototype has been changed to
        return byte size of copied data.
      sql/field.cc:
        Fixed bug #13191.
        Field_string::get_key_image() virtual function was overloaded
        to implement copying of variable length character (UTF-8) fields.
        Field::get_key_image() function prototype has been changed to
        return byte size of copied data.
      sql/key.cc:
        Fixed bug #13191.
        INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
        "Can't find record in ...".
        This error occurs because INSERT...ON DUPLICATE uses
        a wrong procedure to copy field parts for index search.
        key_copy() function has been fixed.
      98c0da4e
    • unknown's avatar
      Fixed bug #20710. · f90870e9
      unknown authored
      This bug occurs when error message length exceeds allowed limit: my_error()
      function outputs "%s" sequences instead of long string arguments.
      
      Formats like %-.64s are very common in errmsg.txt files, however my_error()
      function simply ignores precision of those formats.
      
      
      mysys/my_error.c:
        Fixed bug #20710.
        This bug occurs when error message length exceeds allowed limit: my_error()
        function output "%s" sequences instead of long string arguments.
        my_error() function has been fixed to accept formats like %-.64s.
      mysql-test/t/alter_table.test:
        Added test case for bug #20710.
      mysql-test/r/alter_table.result:
        Added test case for bug #20710.
      f90870e9
    • unknown's avatar
      Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build · 599c6552
      unknown authored
      into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work
      
      
      599c6552
  15. 27 Apr, 2007 1 commit
  16. 26 Apr, 2007 2 commits
  17. 24 Apr, 2007 3 commits
  18. 23 Apr, 2007 2 commits
  19. 20 Apr, 2007 1 commit