1. 21 Mar, 2007 1 commit
  2. 18 Mar, 2007 1 commit
  3. 17 Mar, 2007 3 commits
  4. 16 Mar, 2007 4 commits
  5. 15 Mar, 2007 11 commits
    • joerg@trift2.'s avatar
      Merge trift2.:/MySQL/M50/mysql-5.0 · 40423891
      joerg@trift2. authored
      into  trift2.:/MySQL/M51/mysql-5.1
      40423891
    • svoj@april.(none)'s avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-5.0-engines · 03600868
      svoj@april.(none) authored
      into  mysql.com:/home/svoj/devel/bk/mysql-5.1-engines
      03600868
    • jbruehe/mysqldev@mysql.com/production.mysql.com's avatar
    • svoj@mysql.com/april.(none)'s avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-4.1-engines · 8b325697
      svoj@mysql.com/april.(none) authored
      into  mysql.com:/home/svoj/devel/bk/mysql-5.0-engines
      8b325697
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-4.1 · e25ea78f
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-4.1-merge
      e25ea78f
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 4f46196d
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.0-merge
      4f46196d
    • dlenev@mockturtle.local's avatar
      Merge mockturtle.local:/home/dlenev/src/mysql-5.0-bg25966-2 · bb233cb3
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25966
      bb233cb3
    • 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
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-engines · d9d887ad
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25966
      d9d887ad
  6. 14 Mar, 2007 13 commits
  7. 13 Mar, 2007 7 commits