1. 15 Mar, 2007 1 commit
  2. 14 Mar, 2007 1 commit
    • istruewing@chilla.local's avatar
      Bug#25289 - repair table causes "my_seek.c:56: · 6b7fea5f
      istruewing@chilla.local authored
                  my_seek: Assertion `fd != -1' failed"
      
      In difficult optimize/repair situations the server could crash.
      Under some circumstances the server retries an optimize/repair
      with more elaborate options. But it did not check if the first
      attempt failed so badly that a second one must not be tried.
      
      This could happen when a new data file has been created
      but it was not possible to open it. In this case the
      repair leaves behind a table with closed data file.
      This must not be used for another repair attempt.
      
      We do now detect the closed data file and do not try
      another repair attempt in this situation.
      
      No test case. The required table corruption can not be
      repeated easily. There is a test program attached to
      bug 25433.
      6b7fea5f
  3. 06 Mar, 2007 1 commit
  4. 05 Mar, 2007 1 commit
    • istruewing@chilla.local's avatar
      Bug#26464 - insert delayed + update + merge = corruption · 629fed6c
      istruewing@chilla.local authored
      Using INSERT DELAYED on MERGE tables could lead to table
      corruptions.
      
      The manual lists a couple of storage engines, which can be
      used with INSERT DELAYED. MERGE is not in this list.
      
      The attempt to try it anyway has not been rejected yet.
      This bug was not detected earlier as it can work under
      special circumstances. Most notable is low concurrency.
      
      To be safe, this patch rejects any attempt to use INSERT
      DELAYED on MERGE tables.
      629fed6c
  5. 28 Feb, 2007 1 commit
    • svoj@mysql.com/june.mysql.com's avatar
      BUG#26238 - inserted delayed always inserts 0 for BIT columns · aae6e1ab
      svoj@mysql.com/june.mysql.com authored
      INSERT DELAYED inserts garbage for BIT columns.
      
      When delayed thread clones TABLE object, it didn't adjusted bit_ptr
      to newly created record (though it correctly adjusts ptr and null_ptr).
      
      This is fixed by correctly adjusting bit_ptr when performing a clone.
      With this fix BIT values are stored correctly by INSERT DELAYED.
      aae6e1ab
  6. 20 Feb, 2007 3 commits
  7. 16 Feb, 2007 1 commit
  8. 14 Feb, 2007 3 commits
  9. 13 Feb, 2007 9 commits
  10. 12 Feb, 2007 17 commits
  11. 11 Feb, 2007 2 commits