1. 17 Oct, 2006 1 commit
  2. 02 Oct, 2006 1 commit
  3. 29 Sep, 2006 1 commit
  4. 28 Sep, 2006 1 commit
  5. 27 Sep, 2006 1 commit
  6. 23 Sep, 2006 1 commit
  7. 22 Sep, 2006 3 commits
  8. 15 Sep, 2006 1 commit
  9. 07 Sep, 2006 1 commit
  10. 06 Sep, 2006 1 commit
  11. 31 Aug, 2006 1 commit
  12. 30 Aug, 2006 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#4053: too many of "error 1236: 'binlog truncated in the middle of \ · 2c356ec7
      cmiller@zippy.cornsilk.net authored
      	event' from master"
      
      Since there is no repeatable test case, and this is obviously wrong, this is
      the most conservative change that might possibly work.  
      
      The syscall  read()  wasn't checked for a negative return value for an
      interrupted read.  The kernel  sys_read()  returns -EINTR, and the "library" 
      layer maps that to return value of -1 and sets  errno  to EINTR.  It's 
      impossible (on Linux) for  read()  to set errno EINTR without the return 
      value being -1 .
      
      So, if we're checking for EINTR behavior, we should not require that the
      return value be zero.
      2c356ec7
  13. 29 Aug, 2006 1 commit
  14. 10 Aug, 2006 1 commit
  15. 29 Jul, 2006 1 commit
  16. 28 Jul, 2006 3 commits
  17. 26 Jul, 2006 1 commit
  18. 24 Jul, 2006 1 commit
  19. 21 Jul, 2006 1 commit
  20. 08 Jul, 2006 1 commit
  21. 07 Jul, 2006 2 commits
  22. 05 Jul, 2006 1 commit
  23. 01 Jul, 2006 1 commit
    • cmiller@zippy.(none)'s avatar
      Bug#19006: 4.0 valgrind problems (in test func_str) · 5039184e
      cmiller@zippy.(none) authored
      On exactly-sized Strings, the String::c_ptr() function peeked beyond the
      end of the buffer, possibly into unititialized space to see whether the 
      buffer was NUL-terminated.
      
      In a place that did peek improperly, we now use a c_ptr_safe() function, 
      which doesn't peek where it shouldn't.
      5039184e
  24. 28 Jun, 2006 1 commit
    • ingo@mysql.com's avatar
      Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert" · 99ad23ec
      ingo@mysql.com authored
      It was possible that fetching a record by an exact key value 
      (including the record pointer) could return a record with a 
      different key value. This happened only if a concurrent insert 
      added a record with the searched key value after the fetching 
      statement locked the table for read.
      
      The search succeded on the key value, but the record was
      rejected as it was past the file length that was remembered
      at start of the fetching statement. With other words it was 
      rejected as being a concurrently inserted record.
      
      The action to recover from this problem was to fetch the 
      record that is pointed at by the next key of the index. 
      This was repeated until a record below the file length was 
      found.
      
      I do now avoid this loop if an exact match was searched. 
      If this match is beyond the file length, it is now treated 
      as "key not found". There cannot be another key with the 
      same record pointer.
      99ad23ec
  25. 27 Jun, 2006 1 commit
  26. 26 Jun, 2006 1 commit
    • kent@mysql.com's avatar
      make_sharedlib_distribution.sh: · c36dd286
      kent@mysql.com authored
        For compatibility, don't use {..,..} in pattern matching
      make_binary_distribution.sh:
        Added .dylib and .sl as shared library extensions
      c36dd286
  27. 13 Jun, 2006 1 commit
  28. 20 May, 2006 1 commit
  29. 12 May, 2006 1 commit
    • kent@mysql.com's avatar
      Many files: · 9e77c3a0
      kent@mysql.com authored
        Change mode to -rw-rw-r--
      dbug_add_tags.pl:
        Change mode to -rwxrwxr--
      9e77c3a0
  30. 11 May, 2006 1 commit
  31. 06 May, 2006 1 commit
  32. 04 May, 2006 1 commit
  33. 25 Apr, 2006 2 commits
  34. 11 Apr, 2006 1 commit