1. 09 Feb, 2010 5 commits
  2. 07 Feb, 2010 1 commit
  3. 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
  4. 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
  5. 02 Feb, 2010 1 commit
  6. 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
  7. 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
  8. 28 Jan, 2010 2 commits
  9. 27 Jan, 2010 9 commits
  10. 26 Jan, 2010 3 commits
  11. 25 Jan, 2010 2 commits
    • Andrei Elkin's avatar
      Bug #47142 "slave start until" stops 1 event too late in 4.1 to 5.0 replication · 1c0056b3
      Andrei Elkin authored
      When replicating from 4.1 master to 5.0 slave START SLAVE UNTIL can stop too late.
      The necessary in calculating of the beginning of an event the event's length
      did not correspond to the master's genuine information at the event's execution time.
      That piece of info was changed at the event's relay-logging due to binlog_version<4 event
      conversion by IO thread.
      
      Fixed with storing the master genuine Query_log_event size into a new status
      variable at relay-logging of the event. The stored info is extacted at the event
      execution and participate further to caclulate the correct start position of the event
      in the until-pos stopping routine.
      The new status variable's algorithm will be only active when the event comes
      from the master of version < 5.0 (binlog_version < 4).
      1c0056b3
    • 's avatar
      Manual merge with Conflicts: · 8a66b424
      authored
      sql_udf.cc
      8a66b424
  12. 24 Jan, 2010 1 commit
  13. 22 Jan, 2010 10 commits
    • Sergey Vojtovich's avatar
      a365016f
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot, fixes BUG#49396. · 58ebdfae
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6471 | calvin | 2010-01-16 01:43:27 +0200 (Sat, 16 Jan 2010) | 4 lines
      branches/5.1: fix bug#49396: main.innodb test fails in embedded mode
      
      Change replace_result by using $MYSQLD_DATADIR. Tested in both embedded
      mode and normal server mode.
      58ebdfae
    • Sergey Glukhov's avatar
      Bug#49501 Inefficient information_schema check (system collation), addon · ed79d2ec
      Sergey Glukhov authored
      removed wrongly introduced strlen calls
      ed79d2ec
    • Sergey Vojtovich's avatar
      4c7ea125
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot · 8eac0062
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6492 | sunny | 2010-01-21 09:38:35 +0200 (Thu, 21 Jan 2010) | 1 line
      branches/5.1: Add reference to bug#47621 in the comment.
      8eac0062
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot · 09c84438
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6489 | sunny | 2010-01-21 02:57:50 +0200 (Thu, 21 Jan 2010) | 2 lines
      branches/5.1: Factor out test for bug#44030 from innodb-autoinc.test
      into a separate test/result files.
      09c84438
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot · 6f2fd9e5
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6488 | sunny | 2010-01-21 02:55:08 +0200 (Thu, 21 Jan 2010) | 2 lines
      branches/5.1: Factor out test for bug#44030 from innodb-autoinc.test
      into a separate test/result files.
      6f2fd9e5
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot, fixes BUG#46193. · 8f32c618
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6424 | marko | 2010-01-12 12:22:19 +0200 (Tue, 12 Jan 2010) | 16 lines
      branches/5.1: In innobase_initialize_autoinc(), do not attempt to read
      the maximum auto-increment value from the table if
      innodb_force_recovery is set to at least 4, so that writes are
      disabled. (Bug #46193)
      
      innobase_get_int_col_max_value(): Move the function definition before
      ha_innobase::innobase_initialize_autoinc(), because that function now
      calls this function.
      
      ha_innobase::innobase_initialize_autoinc(): Change the return type to
      void.  Do not attempt to read the maximum auto-increment value from
      the table if innodb_force_recovery is set to at least 4.  Issue
      ER_AUTOINC_READ_FAILED to the client when the auto-increment value
      cannot be read.
      
      rb://144 by Sunny, revised by Marko
      8f32c618
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot · 1dcb80dc
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6422 | marko | 2010-01-12 11:34:27 +0200 (Tue, 12 Jan 2010) | 3 lines
      branches/5.1: Non-functional change:
      Make innobase_get_int_col_max_value() a static function.
      It does not access any fields of class ha_innobase.
      1dcb80dc
    • Sergey Vojtovich's avatar
      Applying InnoDB snapshot, fixes BUG#49238. · 6382f05c
      Sergey Vojtovich authored
      Detailed revision comments:
      
      r6421 | jyang | 2010-01-12 07:59:16 +0200 (Tue, 12 Jan 2010) | 8 lines
      branches/5.1: Fix bug #49238: Creating/Dropping a temporary table
      while at 1023 transactions will cause assert. Handle possible
      DB_TOO_MANY_CONCURRENT_TRXS when deleting metadata in
      row_drop_table_for_mysql().
      
      rb://220, approved by Marko
      6382f05c