1. 10 Oct, 2007 1 commit
  2. 04 Oct, 2007 5 commits
  3. 14 Sep, 2007 1 commit
  4. 10 Sep, 2007 1 commit
  5. 04 Sep, 2007 1 commit
  6. 29 Aug, 2007 5 commits
  7. 13 Aug, 2007 1 commit
  8. 05 Aug, 2007 1 commit
  9. 04 Aug, 2007 1 commit
  10. 02 Aug, 2007 7 commits
  11. 01 Aug, 2007 3 commits
    • jperkin@production.mysql.com's avatar
      Merge jperkin@bk-internal.mysql.com:/home/bk/mysql-4.1-maint · 612fb66d
      jperkin@production.mysql.com authored
      into  production.mysql.com:/usersnfs/jperkin/bk/mysql-4.1-maint
      612fb66d
    • jperkin@production.mysql.com's avatar
      Option 6 tries to grant global privileges at the database level · f5c8c9a8
      jperkin@production.mysql.com authored
      which does not work.  Removing these attempted privileges makes
      this identical to option 5 so remove it completely.  The spirit
      of the program appears to be aimed at database privileges, so do
      not add another option for granting global privileges as it may
      be unexpected.  Fixes bug#14618 (same as previous patch, this
      time applied to -maint tree).
      f5c8c9a8
    • istruewing@chilla.local's avatar
      Bug#29838 - myisam corruption using concurrent select ... and update · e117a36c
      istruewing@chilla.local authored
      When using concurrent insert with parallel index reads, it could
      happen that reading sessions found keys that pointed to records
      yet to be written to the data file. The result was a report of
      a corrupted table. But it was false alert.
      
      When inserting a record in a table with indexes, the keys are
      inserted into the indexes before the record is written to the data
      file. When the insert happens concurrently to selects, an
      index read can find a key that references the record that is not
      yet written to the data file. To avoid any access to such record,
      the select saves the current end of file position when it starts.
      Since concurrent inserts are always appended at end of the data
      file, the select can easily ignore any concurrently inserted record.
      
      The problem was that the ignore was only done for non-exact key
      searches (partial key or using >, >=, < or <=).
      
      The fix is to ignore concurrently inserted records also for
      exact key searches.
      
      No test case. Concurrent inserts cannot be tested with the test
      suite. Test cases are attached to the bug report.
      e117a36c
  12. 31 Jul, 2007 2 commits
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Merge mysql.com:/home/hf/work/029717/my41-29717 · 288ab1aa
      holyfoot/hf@mysql.com/hfmain.(none) authored
      into  mysql.com:/home/hf/work/29717/my41-29717
      288ab1aa
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #29717 INSERT INTO SELECT inserts values even if · f1ee2d06
      holyfoot/hf@mysql.com/hfmain.(none) authored
       SELECT statement itself returns empty.
      
      As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
      can return one row instead of an empty result set.
      
      When GROUP BY only has fields of constant tables
      (with a single row), the optimizer deletes the group_list.
      After that we lose the information about whether we had an
      GROUP BY statement. Though it's important
      as SELECT min(x) from empty_table; and
         SELECT min(x) from empty_table GROUP BY y; have to return
      different results - the first query should return one row,
      second - an empty result set.
      So here we add the 'group_optimized_away' flag to remember this case
      when GROUP BY exists in the query and is removed
      by the optimizer, and check this flag in end_send_group()
      f1ee2d06
  13. 30 Jul, 2007 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_pthread.c: · e99df6fd
      kent@mysql.com/kent-amd64.(none) authored
        Backport of correction for Mac OS X build problem, global variable not
        initiated is "common" and can't be used in shared libraries, unless
        special flags are used (bug#26218)
      e99df6fd
  14. 26 Jul, 2007 3 commits
  15. 22 Jul, 2007 1 commit
  16. 21 Jul, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #29911. · 07e0cd2f
      igor@olga.mysql.com authored
      This bug manifested itself for join queries with GROUP BY and HAVING clauses
      whose SELECT lists contained DISTINCT. It occurred when the optimizer could
      deduce that the result set would have not more than one row.
      The bug could lead to wrong result sets for queries of this type because
      HAVING conditions were erroneously ignored in some cases in the function
      remove_duplicates.   
      07e0cd2f
  17. 20 Jul, 2007 2 commits
  18. 17 Jul, 2007 1 commit
  19. 16 Jul, 2007 1 commit
  20. 14 Jul, 2007 1 commit