1. 06 Nov, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#34384: Slow down on constant conversion. · a8f968b3
      Evgeny Potemkin authored
      When values of different types are compared they're converted to a type that
      allows correct comparison. This conversion is done for each comparison and
      takes some time. When a constant is being compared it's possible to cache the
      value after conversion to speedup comparison. In some cases (large dataset,
      complex WHERE condition with many type conversions) query might be executed
      7% faster.
      
      A test case isn't provided because all changes are internal and isn't visible
      outside.
      
      The behavior of the Item_cache is changed to cache values on the first request
      of cached value rather than at the moment of storing item to be cached.
      A flag named value_cached is added to the Item_cache class. It's set to TRUE
      when cache holds the value of the last stored item.
      Function named cache_value() is added to the Item_cache class and derived classes.
      This function actually caches the value of the saved item.
      Item_cache_xxx::store functions now only store item to be cached and set
      value_cached flag to FALSE.
      Item_cache_xxx::val_xxx functions are changed to call cache_value function
      prior to returning cached value if value_cached is FALSE.
      The Arg_comparator::set_cmp_func function now calls cache_converted_constant
      to cache constants if they need a type conversion.
      The Item_cache::get_cache function is overloaded to allow setting of the
      cache type.
      The cache_converted_constant function is added to the Arg_comparator class.
      It checks whether a value can and should be cached and if so caches it.
      
      sql/item.cc:
        Bug#34384: Slow down on constant conversion.
        Function named cache_value() is added to the Item_cache class and derived classes.
        This function actually caches the value of the saved item.
        Item_cache_xxx::store functions now only store item to be cached and set
        value_cached flag to FALSE.
        Item_cache_xxx::val_xxx functions are changed to call cache_value function
        prior to returning cached value if value_cached is FALSE.
        The Item_cache::get_cache function is overloaded to allow setting of the
        cache type.
      sql/item.h:
        Bug#34384: Slow down on constant conversion.
        A flag named value_cached is added to the Item_cache class. It's set to TRUE
        when we need to start caching values when the store method is called.
        Function named cache_value() is added to the Item_cache class and derived classes.
      sql/item_cmpfunc.cc:
        Bug#34384: Slow down on constant conversion.
        A helper function cache_converted_constant is added to the Arg_comparator class.
        It checks whether a given item can and should be cached and caches it if so.
        The Arg_comparator::set_cmp_func function now calls cache_converted_constant
        to cache constants if they need a type conversion.
      sql/item_cmpfunc.h:
        Bug#34384: Slow down on constant conversion.
        The cache_converted_constant function is added to the Arg_comparator class.
        It checks whether a value can and should be cached and if so caches it.
      sql/item_subselect.cc:
        Bug#34384: Slow down on constant conversion.
        Force immediate caching of subselect result.
      sql/item_xmlfunc.cc:
        Bug#34384: Slow down on constant conversion.
      sql/sp_rcontext.cc:
        Bug#34384: Slow down on constant conversion.
        Force immediate caching of values of an SP CASE function.
      a8f968b3
  2. 26 Oct, 2009 1 commit
  3. 19 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #47788: Crash in TABLE_LIST::hide_view_error on · a06db22c
      Georgi Kodinov authored
        UPDATE + VIEW + SP + MERGE + ALTER
      
      When cleaning up the stored procedure's internal 
      structures the flag to ignore the errors for 
      INSERT/UPDATE IGNORE was not cleaned up.
      As a result error ignoring was on during name 
      resolution. And this is an abnormal situation : the
      SELECT_LEX flag can be on only during query execution.
      
      Fixed by correctly cleaning up the SELECT_LEX flag 
      when reusing the SELECT_LEX in a second execution.
      a06db22c
  4. 26 Oct, 2009 1 commit
  5. 24 Oct, 2009 1 commit
  6. 23 Oct, 2009 8 commits
  7. 22 Oct, 2009 2 commits
  8. 21 Oct, 2009 5 commits
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 5e3f89fd
      Ramil Kalimullin authored
      line 138 when forcing a spatial index
      
      Problem: "Spatial indexes can be involved in the search 
      for queries that use a function such as MBRContains() 
      or MBRWithin() in the WHERE clause".
      Using spatial indexes for JOINs with =, <=> etc.
      predicates is incorrect.
      
      Fix: disable spatial indexes for such queries.
      
      
      mysql-test/r/select.result:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test result.
      mysql-test/t/select.test:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test case.
      sql/sql_select.cc:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - disable spatial indexes for queries which use 
        non-spatial conditions (e.g. NATURAL JOINs).
      5e3f89fd
    • Georgi Kodinov's avatar
      Bug #47780: crash when comparing GIS items from subquery · 98bf634a
      Georgi Kodinov authored
            
      If the first argument to GeomFromWKB function is a geometry
      field then the function just returns its value.
      However in doing so it's not preserving first argument's 
      null_value flag and this causes unexpected null value to
      be returned to the calling function.
            
      Fixed by updating the null_value of the GeomFromWKB function
      in such cases (and all other cases that return a NULL e.g.
      because of not enough memory for the return buffer).
      98bf634a
    • Bjorn Munch's avatar
      merge from 5.1-mtr · 95e77d45
      Bjorn Munch authored
      95e77d45
    • Tatiana A. Nurnberg's avatar
      auto-merge · 5b5fc532
      Tatiana A. Nurnberg authored
      5b5fc532
    • Tatiana A. Nurnberg's avatar
      auto-merge · d689dda1
      Tatiana A. Nurnberg authored
      d689dda1
  9. 20 Oct, 2009 14 commits
    • Tatiana A. Nurnberg's avatar
      manual merge of 28141 · 6293dc7c
      Tatiana A. Nurnberg authored
      6293dc7c
    • Bjorn Munch's avatar
      merge 48149 · 19adf9cc
      Bjorn Munch authored
      19adf9cc
    • Luis Soares's avatar
      BUG#34582: FLUSH LOGS does not close and reopen the binlog index · 3996cd98
      Luis Soares authored
      file
            
      Issuing 'FLUSH LOGS' does not close and reopen indexfile.
      Instead a SEEK_SET is performed.
            
      This patch makes index file to be closed and reopened whenever a
      rotation happens (FLUSH LOGS is issued or binary log exceeds 
      maximum configured size).
      
      mysql-test/suite/binlog/r/binlog_delete_and_flush_index.result:
        Result file.
      mysql-test/suite/binlog/t/binlog_delete_and_flush_index.test:
        Test case.
      sql/log.cc:
        Added LOG_CLOSE_INDEX flag when calling MYSQL_BIN_LOG::close
        from within MYSQL_BIN_LOG::new_file_impl (which should just be
        called whenever a rotation is to happen - FLUSH LOGS issued or
        binlog size exceeds the maximum configured).
      3996cd98
    • Alexander Barkov's avatar
      A post fix for BUG#45645 Mysql server close all connection and restart using lower function · ed7be95b
      Alexander Barkov authored
      - Initialized caseinfo only if it is NULL
      ed7be95b
    • Kristofer Pettersson's avatar
      Automerge · a9ce3864
      Kristofer Pettersson authored
      a9ce3864
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · 8d647d5e
      Satya B authored
      8d647d5e
    • Satya B's avatar
      merge to mysql-5.0-bugteam · c5ab62b7
      Satya B authored
      c5ab62b7
    • Satya B's avatar
      merge mysql-5.0-bugteam to mysql-5.1-bugteam · bef64f0c
      Satya B authored
      bef64f0c
    • Kristofer Pettersson's avatar
      automerge · 34629198
      Kristofer Pettersson authored
      34629198
    • Satya B's avatar
      Fix for Bug #41597 - After rename of user, there are additional grants when · 15ddeb08
      Satya B authored
                           grants are reapplied.
      
      
      After renaming a user and trying to re-apply grants results in additional
      grants.
      
      This is because we use username as part of the key for GRANT_TABLE structure.
      When the user is renamed, we only change the username stored and the hash key
      still contains the old user name and this results in the extra privileges
      
      Fixed by rebuilding the hash key and updating the column_priv_hash structure
      when the user is renamed
      
      mysql-test/r/grant3.result:
        Bug #41597 - After rename of user, there are additional grants when 
                     grants are reapplied.
        
        Testcase for BUG#41597
      mysql-test/t/grant3.test:
        Bug #41597 - After rename of user, there are additional grants when 
                     grants are reapplied.
        
        Testcase for BUG#41597
      sql/sql_acl.cc:
        Bug #41597 - After rename of user, there are additional grants when 
                     grants are reapplied.
        
        Fixed handle_grant_struct() to update the hash key when the user is renamed.
        Added to set_user_details() method to GRANT_NAME class
      15ddeb08
    • Sergey Vojtovich's avatar
      Merge 5.1-bugteam -> 5.1-bugteam-local. · 138414c8
      Sergey Vojtovich authored
      138414c8
    • Sergey Vojtovich's avatar
      Merge 5.1-bugteam -> 5.1-bugteam-local. · ed3e32ea
      Sergey Vojtovich authored
      ed3e32ea
    • unknown's avatar
      Bug #34777 mysqlbinlog: --help output for --base64-output is hard to understand · 93cd66f4
      unknown authored
      There are some problems about help text:
      - It is stated that "auto" is the default twice. It need be stated only once.
      - It is stated that --base64-output is short for --base64-output=always. But that sounds
      like the default is "always", not "auto".
      
      Make the help text clear as following:
      Determine when the output statements should be base64-encoded BINLOG 
      statements: 'never' disables it and works only for binlogs without 
      row-based events; 'auto' prints base64 only when necessary (i.e., 
      for row-based events and format description events); 'always' prints 
      base64 whenever possible. 'always' is for debugging only and should 
      not be used in a production system. If this argument is not given, 
      the default is 'auto'; if it is given with no argument, 'always' is used.
      93cd66f4
    • Tatiana A. Nurnberg's avatar
      Bug#28141: Control C on query waiting on lock causes ERROR 1053 (server shutdown) · 4ebfd532
      Tatiana A. Nurnberg authored
      If a thread is killed in the server, we throw "shutdown" only if one is actually in
      progress; otherwise, we throw "query interrupted".
      
      Control-C in the mysql command-line client is "incremental" now.
      First Control-C sends KILL QUERY (when connected to 5.0+ server, otherwise, see next)
      Next  Control-C sends KILL CONNECTION
      Next  Control-C aborts client.
      
      As the first two steps only pertain to an existing query,
      Control-C will abort the client right away if no query is running.
      
      client will give more detailed/consistent feedback on Control-C now.
      
      
      client/mysql.cc:
        Extends Control-C handling; enhances up feedback to user.
        
        On 5.0+ servers, we try to be nice and send KILL QUERY first
        if Control-C is pressed in the command-line client, but if
        that doesn't work, we now give the user the opportunity to
        send KILL CONNECTION with another Control-C (and to kill the
        client with another Control-C if that somehow doesn't work
        either).
      mysql-test/t/flush_read_lock_kill.test:
        we're getting correct "thread killed" rather than
        "in shutdown" error now
      mysql-test/t/kill.test:
        we're getting correct "thread killed" rather than
        "in shutdown" error now
      mysql-test/t/rpl000001.test:
        we're getting correct "thread killed" rather than
        "in shutdown" error now
      mysql-test/t/rpl_error_ignored_table.test:
        we're getting correct "thread killed" rather than
        "in shutdown" error now
      sql/records.cc:
        make error messages on KILL uniform for rr_*()
        by folding that handling into rr_handle_error()
      sql/sql_class.h:
        Only throw "shutdown" when we have one flagged as being in progress;
        otherwise, throw "query interrupted" as it's likely to be "KILL CONNECTION"
        or related.
      4ebfd532
  10. 19 Oct, 2009 6 commits