1. 16 Feb, 2010 1 commit
  2. 15 Feb, 2010 1 commit
  3. 13 Feb, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#50624: crash in check_table_access during call procedure · 07c30f91
      Davi Arnaut authored
      This bug is just one facet of stored routines not being able to
      detect changes in meta-data (WL#4179). This particular problem
      can be triggered within a single session due to the improper
      management of the pre-locking list if the view is expanded after
      the pre-locking list is calculated.
      
      Since the overall solution for the meta-data detection issue is
      planned for a later release, for now a workaround is used to
      fix this particular aspect that only involves a single session.
      The workaround is to flush the thread-local stored routine cache
      every time a view is created or modified, causing locally cached
      routines to be re-evaluated upon invocation.
      
      mysql-test/r/sp-bugs.result:
        Add test case result for Bug#50624.
      mysql-test/t/sp-bugs.test:
        Add test case for Bug#50624.
      sql/sp_cache.cc:
        Update function description.
      sql/sql_view.cc:
        Invalidate the SP cache if a view is being created or modified.
      07c30f91
  4. 12 Feb, 2010 1 commit
  5. 10 Feb, 2010 2 commits
    • Luis Soares's avatar
      8e07b583
    • Sergey Glukhov's avatar
      Bug#45195 valgrind warnings about uninitialized values in store_record_in_cache() · f2aee237
      Sergey Glukhov authored
      The problem becomes apparent only if HAVE_purify is undefined.
      It related to the part of code placed in open_table_from_share() fuction
      where we initialize record buffer only if HAVE_purify is enabled.
      So in case of HAVE_purify=OFF record buffer is not initialized
      on open table stage.
      Next we read key, find NULL value and update appropriate null bit
      but do not update record buffer. After that the record is stored
      in the join cache(store_record_in_cache). For CHAR fields we
      strip trailing spaces and in our case this procedure uses
      uninitialized record buffer.
      The fix is to skip stripping space procedure in case of null values
      for CHAR fields(partially based on 6.0 JOIN_CACHE implementation).
      
      
      mysql-test/r/join.result:
        test case
      mysql-test/t/join.test:
        test case
      sql/field.cc:
        code updated according to new CACHE_FIELD struct
      sql/sql_select.cc:
        code updated according to new CACHE_FIELD struct
      sql/sql_select.h:
        CACHE_FIELD struct:
        added new fields: Field *field, uint type;
        removed fields: Field_blob *blob_field, bool strip;
      f2aee237
  6. 09 Feb, 2010 5 commits
    • Sergey Vojtovich's avatar
    • Sergey Vojtovich's avatar
      cb2d6a00
    • Sergey Vojtovich's avatar
      7feb91e7
    • Magne Mahre's avatar
      Bug#47974 'TYPE=storage_engine' is deprecated and will be · e0fb0d9d
      Magne Mahre authored
                removed in MySQL 6.0
      
      CREATE TABLE... TYPE= returns the warning "The syntax 
      'TYPE=storage_engine' is deprecated and will be removed in 
      MySQL 6.0. Please use 'ENGINE=storage_engine' instead" 
      
      This syntax is deprecated already from version 5.4.4, so
      the message has been changed.
      
      In addition, the deprecation macro was changed to reflect
      the ServerPT decision not to include version number in the
      warning message.
      
      A number of test result files have been changed as a
      consequence of the change in the deprecation macro.
      e0fb0d9d
    • Sergey Vojtovich's avatar
      BUG#49902 - SELECT returns incorrect results · 0897669c
      Sergey Vojtovich authored
      Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD
      optimization properly. As a result subsequent queries may
      return incomplete rows (fields are initialized to default
      values).
      
      mysql-test/r/group_min_max.result:
        A test case for BUG#49902.
      mysql-test/t/group_min_max.test:
        A test case for BUG#49902.
      sql/opt_range.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/opt_sum.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_select.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/sql_update.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.cc:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      sql/table.h:
        Refactor of KEYREAD optimization switch so that KEYREAD
        handler state is in sync with st_table::key_read flag.
        
        All SQL code is supposed to switch KEYREAD optimization
        via st_table::set_keyread().
      0897669c
  7. 07 Feb, 2010 1 commit
  8. 06 Feb, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #45640: optimizer bug produces wrong results · 994c0f83
      Gleb Shchepa authored
      Grouping by a subquery in a query with a distinct aggregate
      function lead to a wrong result (wrong and unordered
      grouping values).
      
      There are two related problems:
      
      1) The query like this:
      
         SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
         FROM t1 GROUP BY aa
      
      returned wrong result, because the outer reference "t1.a"
      in the subquery was substituted with the Item_ref item.
      
      The Item_ref item obtains data from the result_field object
      that refreshes once after the end of each group. This data
      is not applicable to filesort since filesort() doesn't care
      about groups (and doesn't update result_field objects with
      copy_fields() and so on). Also that data is not applicable
      to group separation algorithm: end_send_group() checks every
      record with test_if_group_changed() that evaluates Item_ref
      items, but it refreshes those Item_ref-s only after the end
      of group, that is a vicious circle and the grouped column
      values in the output are shifted.
      
      Fix: if
             a) we grouping by a subquery and
             b) that subquery has outer references to FROM list
                of the grouping query,
           then we substitute these outer references with
           Item_direct_ref like references under aggregate
           functions: Item_direct_ref obtains data directly
           from the current record.
      
      2) The query with a non-trivial grouping expression like:
      
         SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
         FROM t1 GROUP BY aa+0
      
      also returned wrong result, since JOIN::exec() substitutes
      references to top-level aliases in SELECT list with Item_copy
      caching items. Item_copy items have same refreshing policy
      as Item_ref items, so the whole groping expression with
      Item_copy inside returns wrong result in filesort() and
      end_send_group().
      
      Fix: include aliased items into GROUP BY item tree instead
           of Item_ref references to them.
      
      
      
      mysql-test/r/group_by.result:
        Test case for bug #45640
      mysql-test/t/group_by.test:
        Test case for bug #45640
      sql/item.cc:
        Bug #45640: optimizer bug produces wrong results
        
        Item_field::fix_fields() has been modified to resolve
        aliases in GROUP BY item trees into aliased items instead
        of Item_ref items.
      sql/item.h:
        Bug #45640: optimizer bug produces wrong results
        
        - Item::find_item_processor() has been introduced.
        - Item_ref::walk() has been modified to apply processors
          to itself too (not only to referenced item).
      sql/mysql_priv.h:
        Bug #45640: optimizer bug produces wrong results
        
        fix_inner_refs() has been modified to accept group_list
        parameter.
      sql/sql_lex.cc:
        Bug #45640: optimizer bug produces wrong results
        
        Initialization of st_select_lex::group_fix_field has
        been added.
      sql/sql_lex.h:
        Bug #45640: optimizer bug produces wrong results
        
        The st_select_lex::group_fix_field field has been introduced
        to control alias resolution in Itef_fied::fix_fields.
      sql/sql_select.cc:
        Bug #45640: optimizer bug produces wrong results
        
        - The fix_inner_refs function has been modified to treat
          subquery outer references like outer fields under aggregate
          functions, if they are included in GROUP BY item tree.
        
        - The find_order_in_list function has been modified to
          fix Item_field alias fields included in the GROUP BY item
          trees in a special manner.
      994c0f83
  9. 05 Feb, 2010 3 commits
    • Luis Soares's avatar
      BUG#50780: 'show binary logs' debug assertion when binary · 3ad5d21e
      Luis Soares authored
      logging is disabled
            
      The server would hit an assertion because of a DBUG violation.
      There was a missing DBUG_RETURN and instead a plain return
      was used.
            
      This patch replaces the return with DBUG_RETURN.
      3ad5d21e
    • Luis Soares's avatar
      BUG#50620: Adding an index to a table prevents slave from logging · a0e19f68
      Luis Soares authored
      into slow log
            
      While processing a statement, down the mysql_parse execution
      stack, the thd->enable_slow_log can be assigned to
      opt_log_slow_admin_statements, depending whether one is executing
      administrative statements, such as ALTER TABLE, OPTIMIZE,
      ANALYZE, etc, or not. This can have an impact on slow logging for
      statements that are executed after an administrative statement
      execution is completed.
            
      When executing statements directly from the user this is fine
      because, the thd->enable_slow_log is reset right at the beginning
      of the dispatch_command function, ie, everytime a new statement
      is set is set to execute.
            
      On the other hand, for slave SQL thread (sql_thd) the story is a
      bit different. When in SBR the sql_thd applies statements by
      calling mysql_parse. Right after, it calls log_slow_statement
      function to log them if they take too long. Calling mysql_parse
      directly is fine, but also means that dispatch_command function
      is bypassed. As a consequence, thd->enable_slow_log does not get
      a chance to be reset before the next statement to be executed by
      the sql_thd. If the statement just executed by the sql_thd was an
      administrative statement and logging of admin statements was
      disabled, this means that sql_thd->enable_slow_log will be set to
      0 (disabled) from that moment on. End result: sql_thd stops
      logging slow statements.
            
      We fix this by resetting the value of sql_thd->enable_slow_log to
      the value of opt_log_slow_slave_statements right after
      log_slow_stement is called by the sql_thd.
      a0e19f68
    • Luis Soares's avatar
      BUG#48632: Fix for Bug #23300 Has Not Been Backported · e925bd73
      Luis Soares authored
      To 5.x Release
            
      Notes
      =====
            
      This is a backport of BUG#23300 into 5.1 GA.
            
      Original cset revid (in betony):
      luis.soares@sun.com-20090929140901-s4kjtl3iiyy4ls2h
      
      Description
      ===========
            
      When using replication, the slave will not log any slow query
      logs queries replicated from the master, even if the
      option "--log-slow-slave-statements" is set and these take more
      than "log_query_time" to execute.
                          
      In order to log slow queries in replicated thread one needs to
      set the --log-slow-slave-statements, so that the SQL thread is
      initialized with the correct switch. Although setting this flag
      correctly configures the slave thread option to log slow queries,
      there is an issue with the condition that is used to check
      whether to log the slow query or not. When replaying binlog
      events the statement contains the SET TIMESTAMP clause which will
      force the slow logging condition check to fail. Consequently, the
      slow query logging will not take place.
                          
      This patch addresses this issue by removing the second condition
      from the log_slow_statements as it prevents slow queries to be
      binlogged and seems to be deprecated.
      e925bd73
  10. 04 Feb, 2010 1 commit
    • Luis Soares's avatar
      BUG#50451: rpl_loaddata_concurrent fails sporadically · 713c5a64
      Luis Soares authored
      When using MyIsam tables and processing concurrent DML
      statements, the server may be sending back an OK to the client
      before actually finishing the transaction commit procedure. This
      has been reported before in BUG@37521 and BUG@29334.
      
      This particular test case gets affected, because it performs the
      following sequence:
        
        connect (conn2, ...)
        connection conn2;
        LOAD DATA CONCURRENT ...
        disconnect (conn2, ...)
        connection master;
        sync_slave_with_master
        diff_tables
      
      At this point diff_tables may report difference in the table
      content (the master seems to be missing the conn2 rows). 
      
      To workaround this MyISAM concurrent DML statements issue and
      make this test case deterministic, we wait on conn2 until the
      rows inserted show up in the table. After this the test case
      proceeds as normally would before this patch.
      713c5a64
  11. 02 Feb, 2010 2 commits
    • Kent Boortz's avatar
      Changes to be able to create source TAR packages with longer · 673ec7b2
      Kent Boortz authored
      path names than 99 characters, using the USTAR format of the
      resulting source TAR.
      
      To be able to specify the use of USTAR when creating the source
      TAR, we needed both to update the GNU autotools version requirements
      slightly, and update the initiation of the tools to use more
      modern constructs.
      673ec7b2
    • Sergey Vojtovich's avatar
      BUG#50351 - ft_min_word_len=2 Causes query to hang · dac9e518
      Sergey Vojtovich authored
      Performing fulltext prefix search (a word with truncation
      operator) may cause a dead-loop. ft_min_word_len value
      doesn't matter actually.
      
      The problem was introduced along with "smarter index merge"
      optimization.
      
      mysql-test/r/fulltext.result:
        A test case for BUG#50351.
      mysql-test/t/fulltext.test:
        A test case for BUG#50351.
      storage/myisam/ft_boolean_search.c:
        When going up to first-level tree, we need to restore docid[0],
        so it informs fulltext index merge not to enter this second-level
        tree again (avoiding dead-loop).
      dac9e518
  12. 01 Feb, 2010 1 commit
    • Mattias Jonsson's avatar
      Bug#42438: Crash ha_partition::change_table_ptr · 16c8298a
      Mattias Jonsson authored
      There was two problems:
      The first was the symptom, caused by bad error handling in
      ha_partition. It did not handle print_error etc. when
      having no partitions (when used by dummy handler).
      
      The second was the real problem that when dropping tables
      it reused the table type (storage engine) from when the lock
      was asked for, not the table type that it had when gaining
      the exclusive name lock. So that it tried to delete tables
      from wrong storage engines.
      
      Solutions for the first problem was to accept some handler
      calls to the partitioning handler even if it was not setup
      with any partitions, and also if possible fallback
      to use the base handler's default functions.
      
      Solution for the second problem was to remove the optimization
      to reuse the definition from the cache, instead always check
      the frm-file when holding the LOCK_open mutex
      
      (updated with a fix for a debug print crash and better
      comments as required by reviewer, and removed optimization
      to avoid reading the frm-file).
      
      mysql-test/r/partition_debug_sync.result:
        Bug#42438: Crash ha_partition::change_table_ptr
        
        New result file using DEBUG_SYNC for deterministic results.
      mysql-test/t/partition_debug_sync.test:
        Bug#42438: Crash ha_partition::change_table_ptr
        
        New test file using DEBUG_SYNC for deterministic results.
      sql/ha_partition.cc:
        Bug#42438: Crash ha_partition::change_table_ptr
        
        allow some handler calls, used by error handling, even when
        no partitions are setup. Fallback to default handling if possible.
      sql/sql_base.cc:
        Bug#42438: Crash ha_partition::change_table_ptr
        
        Added DEBUG_SYNC point for deterministic test cases.
      sql/sql_table.cc:
        Bug#42438: Crash ha_partition::change_table_ptr
        
        Always use the table type written in the .frm-file
        (i.e. the current table type) when deleting a table.
        
        Moved the check for log-table to not depend of the cache.
        
        Added DEBUG_SYNC points for deterministic test cases.
      16c8298a
  13. 29 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #49324: more valgrind errors in test_if_skip_sort_order · 6d38c898
      Georgi Kodinov authored
      Fixed 2 problems :
      1. test_if_order_by_key() was continuing on the primary key
      as if it has a primary key suffix (as the secondary keys do).
      This leads to crashes in ORDER BY <pk>,<pk>.
      Fixed by not treating the primary key as the secondary one
      and not depending on it being clustered with a primary key.
      2. The cost calculation was trying to read the records 
      per key when operating on ORDER BYs that order on all of the 
      secondary key + some of the primary key.
      This leads to crashes because of out-of-bounds array access.
      Fixed by assuming we'll find 1 record per key in such cases.
      6d38c898
  14. 05 Feb, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#49025: mysqld-debug: missing DBUG_RETURN or DBUG_VOID_RETURN macro in function "?func" · b8eaa81d
      Davi Arnaut authored
      The problem was that the dbug facility was being used after the
      per-thread dbug state had already been finalized. The was present
      in a few functions which invoked decrement_handler_count, which
      in turn invokes my_thread_end on Windows. In my_thread_end, the
      per-thread dbug state is finalized. Any use after the state is
      finalized ends up creating a new state.
      
      The solution is to process the exit of a function before the
      decrement_handler_count function is called.
      
      
      sql/mysqld.cc:
        Process the function exit before decrement_handler_count is
        called, as it can end the per-thread dbug state on Windows.
      b8eaa81d
  15. 28 Jan, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#50423: Crash on second call of a procedure dropping a trigger · d6ab925c
      Davi Arnaut authored
      The problem was that a DROP TRIGGER statement inside a stored
      procedure could cause a crash in subsequent invocations. This
      was due to the addition, on the first execution, of a temporary
      table reference to the stored procedure query table list. In
      a subsequent invocation, there would be a attempt to reinitialize
      the temporary table reference, which by then was already gone.
      
      The solution is to backup and reset the query table list each
      time a trigger needs to be dropped. This ensures that any temp
      changes to the query table list are discarded. It is safe to
      do so at this time as drop trigger is restricted from more
      complicated scenarios (ie, not allowed within stored functions,
      etc).
      
      mysql-test/r/sp-bugs.result:
        Add test case result for Bug#50423
      mysql-test/t/sp-bugs.test:
        Add test case for Bug#50423
      sql/sql_trigger.cc:
        Backup and reset the query table list.
        Remove now unnecessary manual reset of the query table list.
      d6ab925c
  16. 12 Feb, 2010 13 commits
    • Joerg Bruehe's avatar
      e024afac
    • Joerg Bruehe's avatar
      Automerge from central branch. · ca6ec790
      Joerg Bruehe authored
      ca6ec790
    • Joerg Bruehe's avatar
      ac77988a
    • Joerg Bruehe's avatar
    • Sergey Vojtovich's avatar
      8aeafbd5
    • Sergey Vojtovich's avatar
      6bc7d383
    • Sergey Vojtovich's avatar
      e3eafe84
    • Sergey Vojtovich's avatar
      BUG#48757 - missing .ARZ file causes server crash · 91f0212c
      Sergey Vojtovich authored
      Server crashes when accessing ARCHIVE table with missing
      .ARZ file.
      
      When opening a table, ARCHIVE didn't properly pass through
      error code from lower level azopen() to higher level open()
      method.
      
      mysql-test/r/archive.result:
        A test case for BUG#48757.
      mysql-test/t/archive.test:
        A test case for BUG#48757.
      storage/archive/ha_archive.cc:
        Pass through error code from azopen().
      91f0212c
    • Sergey Vojtovich's avatar
      BUG#49628 - corrupt table after legal SQL, LONGTEXT column · 62933c50
      Sergey Vojtovich authored
      Bulk REPLACE or bulk INSERT ... ON DUPLICATE KEY UPDATE may
      break dynamic record MyISAM table.
      
      The problem is limited to bulk REPLACE and INSERT ... ON
      DUPLICATE KEY UPDATE, because only these operations may
      be done via UPDATE internally and may request write cache.
      
      When flushing write cache, MyISAM may write remaining
      cached data at wrong position. Fixed by requesting write
      cache to seek to a correct position.
      
      mysql-test/r/myisam.result:
        A test case for BUG#49628.
      mysql-test/t/myisam.test:
        A test case for BUG#49628.
      storage/myisam/mi_dynrec.c:
        delete_dynamic_record() may change data file position.
        IO cache must be notified as it may still have cached
        data, which has to be flushed later.
      62933c50
    • Sergey Vojtovich's avatar
      BUG#48438 - crash with error in unioned query against merge · 9d0c1ce5
      Sergey Vojtovich authored
                  table and view...
      
      Invalid memory reads after a query referencing MyISAM table
      multiple times with write lock. Invalid memory reads may
      lead to server crash, valgrind warnings, incorrect values
      in INFORMATION_SCHEMA.TABLES.{TABLE_ROWS, DATA_LENGTH,
      INDEX_LENGTH, ...}.
      
      This may happen when one of the table instances gets closed
      after a query, e.g. out of slots in open tables cache. UNION,
      MERGE and VIEW are irrelevant.
      
      The problem was that MyISAM didn't restore state info
      pointer to default value.
      
      myisam/mi_locking.c:
        When a query is referencing MyISAM table multiple times
        with a write lock, all table instances share the same
        state info, pointing to MI_INFO::save_state of
        "primary" table instance.
        
        When lock is released, state pointer was restored only
        for the primary table instance. Secondary table instances
        are still pointing to save_state of primary table
        instance.
        
        Primary table instance may get closed, leaving secondary
        table instances state pointer pointing to freed memory.
        
        That's mostly ok, since next lock will update state info
        pointer to correct value. But there're some cases, when
        this secondary table instance state info is accessed
        without a lock, e.g. INFORMATION_SCHEMA, MERGE (in 5.1
        and up), MyISAM itself for DBUG purposes.
        
        Restore default value of state pointer unconditionally,
        for both primary and secondary table instances.
      mysql-test/r/myisam.result:
        A test case for BUG#48438.
      mysql-test/t/myisam.test:
        A test case for BUG#48438.
      9d0c1ce5
    • Sergey Glukhov's avatar
      automerge · 1805fcdc
      Sergey Glukhov authored
      1805fcdc
    • Sergey Glukhov's avatar
      Bug#48294 assertion when creating a view based on some row() construct in select query · 46cffd7f
      Sergey Glukhov authored
      In case of 'CREATE VIEW' subselect transformation does not happen(see JOIN::prepare).
      During fix_fields Item_row may call is_null() method for its arugmens which
      leads to item calculation(wrong subselect in our case as
      transformation did not happen before). This is_null() call
      does not make sence for 'CREATE VIEW'.
      Note:
      Only Item_row is affected because other items don't call is_null() 
      during fix_fields() for arguments.
      
      mysql-test/r/view.result:
        test case
      mysql-test/t/view.test:
        test case
      sql/item_row.cc:
        skip is_null() call in case of 'CREATE VIEW' as unnecessary.
      46cffd7f
    • Davi Arnaut's avatar
      Move test case. Embedded server does not support privilege · 80164ae9
      Davi Arnaut authored
      related bits.
      80164ae9
  17. 11 Feb, 2010 2 commits
  18. 10 Feb, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#48449: hang on show create view after upgrading when view contains function of view · 63817720
      Davi Arnaut authored
      SHOW CREATE TABLE on a view (v1) that contains a function whose
      statement uses another view (v2), could trigger a infinite loop
      if the view referenced within the function causes a warning to
      be raised while opening the said view (v2).
      
      The problem was a infinite loop over the stack of internal error
      handlers. The problem would be triggered if the stack contained
      two or more handlers and the first two handlers didn't handle the
      raised condition. In this case, the loop variable would always
      point to the second handler in the stack.
      
      The solution is to correct the loop variable assignment so that
      the loop is able to iterate over all handlers in the stack.
      
      mysql-test/r/view.result:
        Add test case result for Bug#48449.
      mysql-test/std_data/bug48449.frm:
        Add a incomplete view definition that causes a warning to be
        issued.
      mysql-test/t/view.test:
        Add test case for Bug#48449
      sql/sql_class.cc:
        Iterate over all handlers in the stack.
      63817720
  19. 03 Feb, 2010 1 commit