1. 17 Mar, 2007 1 commit
  2. 16 Mar, 2007 7 commits
  3. 15 Mar, 2007 11 commits
    • 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
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 3d0df38f
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/27033-bug-5.0-opt-mysql
      3d0df38f
    • evgen@moonbone.local's avatar
      Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were · 92c85582
      evgen@moonbone.local authored
      touched but not actually changed.
      
      The LAST_INSERT_ID() is reset to 0 if no rows were inserted or changed.
      This is the case when an INSERT ... ON DUPLICATE KEY UPDATE updates a row
      with the same values as the row contains.
      
      Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows
      successfully inserted or touched.
      The new 'touched' field is added to the COPY_INFO structure. It holds the
      number of rows that were touched no matter whether they were actually
      changed or not.
      92c85582
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Merge mysql.com:/home/hf/work/26833/my50-26833 · 2e3ce3c2
      holyfoot/hf@mysql.com/hfmain.(none) authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      2e3ce3c2
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Merge bk@192.168.21.1:mysql-5.0 · 21847d68
      holyfoot/hf@mysql.com/hfmain.(none) authored
      into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
      21847d68
    • 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-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
  4. 14 Mar, 2007 11 commits
  5. 13 Mar, 2007 7 commits
  6. 12 Mar, 2007 3 commits