1. 24 Feb, 2010 1 commit
    • Luis Soares's avatar
      BUG#51251: Wrong binlogging in case of TRUNCATE <temporary InnoDB table> · 1fe647a4
      Luis Soares authored
      For temporary tables that are created with an engine that does
      not provide the HTON_CAN_RECREATE, the truncate operation is
      performed resorting to the optimized handler::ha_delete_all_rows
      method. However, this means that the truncate will share
      execution path, from mysql_delete, with truncate on regular
      tables and other delete operations. As a consequence the truncate
      operation, for the temporary table is logged, even if in row mode
      because there is no distinction between this and the other delete
      operations at binlogging time.
      
      We fix this by checking if: (i) the binlog format, when the
      truncate operation was issued, is ROW; (ii) if the operation is a
      truncate; and (iii) if the table is a temporary table; before
      writing to the binary log. If all three conditions are met, we
      skip writing to the binlog. A side effect of this fix is that we
      limit the scope of setting and resetting the
      current_stmt_binlog_row_based. Now we just set and reset it
      inside mysql_delete in the boundaries of the
      handler::ha_write_row loop. This way we have access to
      thd->current_stmt_binlog_row_based real value inside
      mysql_delete.
      1fe647a4
  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 · a4dd7f95
      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.
      a4dd7f95
  4. 28 Jan, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#50423: Crash on second call of a procedure dropping a trigger · d7797f51
      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).
      d7797f51
  5. 12 Feb, 2010 13 commits
  6. 11 Feb, 2010 2 commits
  7. 10 Feb, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#48449: hang on show create view after upgrading when view contains function of view · be632a2f
      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.
      be632a2f
  8. 07 Feb, 2010 1 commit
  9. 06 Feb, 2010 1 commit
    • Gleb Shchepa's avatar
      Bug #45640: optimizer bug produces wrong results · 57e5f848
      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.
      57e5f848
  10. 05 Feb, 2010 3 commits
    • Luis Soares's avatar
      BUG#50780: 'show binary logs' debug assertion when binary · a26ab94e
      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.
      a26ab94e
    • Luis Soares's avatar
      BUG#50620: Adding an index to a table prevents slave from logging · d0c74a61
      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.
      d0c74a61
    • Luis Soares's avatar
      BUG#48632: Fix for Bug #23300 Has Not Been Backported · 1458896d
      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.
      1458896d
  11. 03 Feb, 2010 1 commit
  12. 02 Feb, 2010 2 commits
  13. 01 Feb, 2010 1 commit
  14. 29 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #49324: more valgrind errors in test_if_skip_sort_order · f11861c2
      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.
      f11861c2
  15. 05 Feb, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#49025: mysqld-debug: missing DBUG_RETURN or DBUG_VOID_RETURN macro in function "?func" · 82b30bbe
      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.
      82b30bbe
  16. 29 Jan, 2010 2 commits
  17. 27 Jan, 2010 2 commits
  18. 11 Feb, 2010 2 commits
    • Staale Smedseng's avatar
      Bug #47905 stored procedures with conditional statements not · c1a6dc50
      Staale Smedseng authored
      being logged to slow query log
      
      The problem is that the execution time for a multi-statement
      stored procedure as a whole may not be accurate, and thus not
      be entered into the slow query log even if the total time
      exceeds long_query_time. The reason for this is that
      THD::utime_after_lock used for time calculation may be reset
      at the start of each new statement, possibly leaving the total
      SP execution equal to the time spent executing the last
      statement in the SP.
      
      This patch stores the utime on start of SP execution, and
      restores it on exit of SP execution. A test is added.
      c1a6dc50
    • Martin Hansson's avatar
      Merge of Bug#49534 · 83b40ad9
      Martin Hansson authored
      83b40ad9
  19. 10 Feb, 2010 3 commits
    • Luis Soares's avatar
      9b0a91c1
    • Sergey Glukhov's avatar
      Bug#45195 valgrind warnings about uninitialized values in store_record_in_cache() · e5a38da7
      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).
      e5a38da7
    • Martin Hansson's avatar
      Bug#49534: multitable IGNORE update with sql_safe_updates · 2a22dc2e
      Martin Hansson authored
      error causes debug assertion
      
      The IGNORE option of the multiple-table UPDATE command was
      not intended to suppress errors caused by the
      sql_safe_updates mode. This flag will raise an error if the
      execution of UPDATE does not use a key for row retrieval,
      and should continue do so regardless of the IGNORE option.
      
      However the implementation of IGNORE does not support
      exceptions to the rule; it always converts errors to
      warnings and cannot be extended. The Internal_error_handler
      interface offers the infrastructure to handle individual
      errors, making sure that the error raised by
      sql_safe_updates is not silenced.
      
      Fixed by implementing an Internal_error_handler and using it
      for UPDATE IGNORE commands.
      2a22dc2e