1. 26 Oct, 2009 1 commit
  2. 20 Oct, 2009 1 commit
  3. 19 Oct, 2009 2 commits
  4. 18 Oct, 2009 1 commit
  5. 17 Oct, 2009 1 commit
  6. 16 Oct, 2009 10 commits
  7. 15 Oct, 2009 8 commits
  8. 14 Oct, 2009 13 commits
    • Jorgen Loland's avatar
      merge · aea42df6
      Jorgen Loland authored
      aea42df6
    • Jorgen Loland's avatar
      Followup patch for BUG#47280 · a91b1826
      Jorgen Loland authored
      Temporary tables may set join->group to 0 even though there is 
      grouping. Also need to test if sum_func_count>0 when JOIN::exec() 
      decides whether to present results in a grouped manner.
      a91b1826
    • Georgi Kodinov's avatar
      merge · a820c732
      Georgi Kodinov authored
      a820c732
    • Georgi Kodinov's avatar
      merge · 88aa7af8
      Georgi Kodinov authored
      88aa7af8
    • Georgi Kodinov's avatar
      version change · 8fc8d661
      Georgi Kodinov authored
      8fc8d661
    • Georgi Kodinov's avatar
      merge · 9449be58
      Georgi Kodinov authored
      9449be58
    • Georgi Kodinov's avatar
      merged main to mysql-5.0-bugteam · b251cbd5
      Georgi Kodinov authored
      b251cbd5
    • Georgi Kodinov's avatar
      merged 5.1-main · 4bc86808
      Georgi Kodinov authored
      4bc86808
    • He Zhenxing's avatar
      Attempt to fix Windows testcase output issue · adab17b9
      He Zhenxing authored
      adab17b9
    • Jorgen Loland's avatar
      Bug#47280 - strange results from count(*) with order by multiple · bf0aa2bd
      Jorgen Loland authored
                  columns without where/group
                           
      Simple SELECT with implicit grouping used to return many rows if
      the query was ordered by the aggregated column in the SELECT
      list. This was incorrect because queries with implicit grouping
      should only return a single record.
                                    
      The problem was that when JOIN:exec() decided if execution needed
      to handle grouping, it was assumed that sum_func_count==0 meant
      that there were no aggregate functions in the query. This
      assumption was not correct in JOIN::exec() because the aggregate
      functions might have been optimized away during JOIN::optimize().
                        
      The reason why queries without ordering behaved correctly was
      that sum_func_count is only recalculated if the optimizer chooses
      to use temporary tables (which it does in the ordered case).
      Hence, non-ordered queries were correctly treated as grouped.
                        
      The fix for this bug was to remove the assumption that
      sum_func_count==0 means that there is no need for grouping. This
      was done by introducing variable "bool implicit_grouping" in the
      JOIN object.
      bf0aa2bd
    • sunanda.menon@sun.com's avatar
      85f00a96
    • Bjorn Munch's avatar
      Bug #46007 Tests fail due to a crash while running 'check testcase before test' · 23306c56
      Bjorn Munch authored
      Difficult to debug due to lacking report
      This does not solve the real issue, but extracts server log when it happens
      Forst commit was incomplete, didn't cover all cases
      23306c56
    • 's avatar
      Bug#46640: output from mysqlbinlog command in 5.1 breaks replication · 0ece5891
      authored
            
      The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
      the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
      id stored inside the events of the BINLOG statement rather than the id of the running 
      server.
            
      Fix by rearranging code a bit so that only relevant parts of the code are executed by
      the BINLOG statement, and the server_id of the server executing the statements will 
      not be overrided by the server_id stored in the 'format description BINLOG statement'.
      0ece5891
  9. 13 Oct, 2009 3 commits
    • karen.langford@sun.com's avatar
      5ad32f3e
    • karen.langford@sun.com's avatar
      c06a3c4f
    • Alexey Kopytov's avatar
      Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN · 5db734a8
      Alexey Kopytov authored
       
      The problem was in incorrect handling of predicates involving 
      NULL as a constant value by the range optimizer.  
       
      For example, when creating a SEL_ARG node from a condition of 
      the form "field < const" (which would normally result in the 
      "NULL < field < const" SEL_ARG),  the special case when "const" 
      is NULL was not taken into account, so "NULL < field < NULL" 
      was produced for the "field < NULL" condition. 
       
      As a result, SEL_ARG structures of this form could not be 
      further optimized which in turn could lead to incorrectly 
      constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
      structures to always form a sequence of ordered disjoint 
      intervals could enter an infinite loop under some 
      circumstances. 
       
      Fixed by changing get_mm_leaf() so that for any sargable 
      predicate except "<=>" involving NULL as a constant, "empty" 
      SEL_ARG is returned, since such a predicate is always false. 
      5db734a8