into  dev3-240.dev.cn.tlan:/home/justin.he/mysql/mysql-5.1/mysql-5.1-new-ndb-merge


storage/ndb/src/ndbapi/NdbBlob.cpp:
  Auto merged
storage/ndb/test/ndbapi/testBlobs.cpp:
  Auto merged

into  trift2.:/MySQL/M51/mysql-5.1


configure.in:
  Null-merge, a 5.00 version change does not affect 5.1

into  mysql.com:/home/svoj/devel/bk/mysql-5.1-engines

into  mysql.com:/home/svoj/devel/bk/mysql-5.0-engines

into  mysql.com:/home/hartmut/projects/mysql/dev/bug-trees/mysql-5.1-bug25933

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new-ndb


storage/ndb/src/kernel/blocks/suma/Suma.cpp:
  Auto merged
storage/ndb/test/run-test/daily-basic-tests.txt:
  Auto merged

  Fix bug in SUMA::resend_bucket which could cause mysqld to crash


storage/ndb/src/kernel/blocks/suma/Suma.cpp:
  Remove *len* part from sz,
    or an extra word will be sent (sometimes) which will cause event-api barf
storage/ndb/test/ndbapi/test_event.cpp:
  test prg for bug#27169
storage/ndb/test/run-test/daily-basic-tests.txt:
  test prg for bug#27169

into  mockturtle.local:/home/dlenev/src/mysql-4.1-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-merge

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new-ndb


storage/ndb/test/src/UtilTransactions.cpp:
  Auto merged

into  perch.ndb.mysql.com:/home/jonas/src/51-telco-gca


storage/ndb/test/src/UtilTransactions.cpp:
  Auto merged

  reset rowcount on temporary error during scan of base table

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25966


sql/mysqld.cc:
  Auto merged
sql/sp_head.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg25966-2


sql/mysqld.cc:
  Auto merged

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.


sql/mysqld.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of other connections.
sql/sp_head.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of further statements.
sql/sql_parse.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of further statements.

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.


sql/mysqld.cc:
  We should not forget to reset THD::mysys_var::abort after kill operation
  if we are going to use thread to which this operation was applied for
  handling of other connections.

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25966

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new-ndb

  fix test_event -n EventOperationApplier


storage/ndb/test/ndbapi/test_event.cpp:
  fix potential race
storage/ndb/test/src/HugoCalculator.cpp:
  genrate longer varsize keys

into  mysql.com:/home/kent/bk/tmp/mysql-5.1-build

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

  Updated to version 0.6 of the text


EXCEPTIONS-CLIENT:
  Updated to version 0.6 of the text

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new-ndb

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new-ndb


storage/ndb/test/tools/listen.cpp:
  Auto merged
storage/ndb/src/kernel/blocks/suma/Suma.cpp:
  merge

    Handle API failure during resend
    API failure could cause release of table object, which will make resend crash
      when dereferencing table object
      
    Solution, use table_id+hash+schemaversion instead of *raw* pointer in resend



storage/ndb/src/kernel/blocks/suma/Suma.cpp:
  Handle API failure during resend
  API failure could cause release of table object, which will make resend crash
    when dereferencing table object
        
  Solution, use table_id+hash+schemaversion instead of *raw* pointer in resend
storage/ndb/test/tools/listen.cpp:
  add new events

into  mysql.com:/home/kent/bk/tmp/mysql-5.1-build


configure.in:
  Auto merged
storage/ndb/src/ndbapi/NdbBlob.cpp:
  Auto merged
storage/ndb/test/ndbapi/testBlobs.cpp:
  Auto merged

into  mysql.com:/home/kent/bk/tmp/mysql-5.1-build

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build


configure.in:
  Auto merged

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build

into  mysql.com:/home/kent/bk/tmp/mysql-4.1-build


configure.in:
  SCCS merged

  Added test for sched_yield() possibly in -lposix4 on Solaris


configure.in:
  Added test for sched_yield() possibly in -lposix4 on Solaris

into  dev3-240.dev.cn.tlan:/home/justin.he/mysql/mysql-5.1/mysql-5.1-new-ndb-bj

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new-ndb


storage/ndb/src/kernel/blocks/suma/Suma.cpp:
  Auto merged

  Make sure not to handle API_FAILREQ if it's already handled


storage/ndb/src/kernel/blocks/suma/Suma.cpp:
  Make sure not to handle API_FAILREQ if it's already handled

into  blade08.mysql.com:/data0/istruewing/autopush/mysql-5.1-bug25460

into  dev3-240.dev.cn.tlan:/home/justin.he/mysql/mysql-5.1/mysql-5.1-new-ndb-bj.merge


storage/ndb/src/kernel/blocks/dbtup/DbtupGen.cpp:
  Auto merged