1. 25 Mar, 2007 1 commit
  2. 15 Mar, 2007 4 commits
    • istruewing@chilla.local's avatar
      Merge chilla.local:/home/mydev/mysql-4.1-bug25289 · 81c086a6
      istruewing@chilla.local authored
      into  chilla.local:/home/mydev/mysql-5.0-bug25289
      81c086a6
    • dlenev@mockturtle.local's avatar
      Merge mockturtle.local:/home/dlenev/src/mysql-4.1-bg25966 · e4f88d52
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg25966-2
      e4f88d52
    • dlenev@mockturtle.local's avatar
      Fix for bug #25966 "2MB per second endless memory consumption after LOCK · 01bd08b5
      dlenev@mockturtle.local authored
      TABLE ... WRITE".
      
      Memory and CPU hogging occured when connection which had to wait for table
      lock was serviced by thread which previously serviced connection that was
      killed (note that connections can reuse threads if thread cache is enabled).
      One possible scenario which exposed this problem was when thread which
      provided binlog dump to replication slave was implicitly/automatically
      killed when the same slave reconnected and started pulling data through
      different thread/connection.
      The problem also occured when one killed particular query in connection
      (using KILL QUERY) and later this connection had to wait for some table
      lock.
      
      This problem was caused by the fact that thread-specific mysys_var::abort
      variable, which indicates that waiting operations on mysys layer should
      be aborted (this includes waiting for table locks), was set by kill
      operation but was never reset back. So this value was "inherited" by the
      following statements or even other connections (which reused the same
      physical thread). Such discrepancy between this variable and THD::killed
      flag broke logic on SQL-layer and caused CPU and memory hogging.
      
      This patch tries to fix this problem by properly resetting this member.
      
      There is no test-case associated with this patch since it is hard to test
      for memory/CPU hogging conditions in our test-suite.
      01bd08b5
    • dlenev@mockturtle.local's avatar
      Fix for bug #25966 "2MB per second endless memory consumption after LOCK · f2cb6641
      dlenev@mockturtle.local authored
      TABLE ... WRITE".
      
      CPU hogging occured when connection which had to wait for table lock was
      serviced by thread which previously serviced connection that was killed
      (note that connections can reuse threads if thread cache is enabled).
      One possible scenario which exposed this problem was when thread which
      provided binlog dump to replication slave was implicitly/automatically
      killed when the same slave reconnected and started pulling data through
      different thread/connection.
      In 5.* versions memory hogging was added to CPU hogging. Moreover in
      those versions the problem also occured when one killed particular query
      in connection (using KILL QUERY) and later this connection had to wait for
      some table lock.
      
      This problem was caused by the fact that thread-specific mysys_var::abort
      variable, which indicates that waiting operations on mysys layer should
      be aborted (this includes waiting for table locks), was set by kill
      operation but was never reset back. So this value was "inherited" by the
      following statements or even other connections (which reused the same
      physical thread). Such discrepancy between this variable and THD::killed
      flag broke logic on SQL-layer and caused CPU and memory hogging.
      
      This patch tries to fix this problem by properly resetting this member.
      
      There is no test-case associated with this patch since it is hard to test
      for memory/CPU hogging conditions in our test-suite.
      f2cb6641
  3. 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
  4. 13 Mar, 2007 6 commits
  5. 10 Mar, 2007 6 commits
  6. 09 Mar, 2007 12 commits
  7. 08 Mar, 2007 10 commits