into  perch.ndb.mysql.com:/home/jonas/src/50-work

  Reset logpartstate if file_change_problem after writeing of zero page is done

  Better error message when failing to read either of 2 DIH schema files

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  crash if system restart with more than 4096 fragments
  solution: continueb enable expand check loop

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  Fix testNodeRestart -n DuringLCP and others (add stopTest() at end of test :-))

  force close of scan (of outstanding scan_frag)

  allow user to specify scan batch size in readTuples

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  part 1 - make sure return code is propagated from request tracker

  set max value on ports

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  also close scan which are in "delivered" state, as it's impossible to release locks afterwards

  backport from 5.1

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  Dont be too aggressive in Dbtc::nodeFailCheckTransaction
  let it timeout by 1, so that it does not assert that it has waited too long
  old impl. set timeotu value to 0, making timeout = (ctcTimer - 0) which could be quite big.

  Add mutex surronding sessions, as ndb_mgmd now actively tries to go and  "purge stale sessions"

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

into  rurik.mysql.com:/home/igor/mysql-5.0

into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0

into  rurik.mysql.com:/home/igor/mysql-4.1

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136

recalculating results

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var

A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct 
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.

into mysql.com:/home/psergey/mysql-5.0-bug16798-merge

into mysql.com:/home/psergey/mysql-4.1-bug16798

into  mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-merge

into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501

into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501

into  mysql.com:/home/mydev/mysql-4.1-bug10405

into  mysql.com:/home/mydev/mysql-5.0-bug10405

into mysql.com:/home/psergey/mysql-4.1-bug16798

into mysql.com:/home/psergey/mysql-5.0-bug16798-merge

The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will 
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this 
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.

The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().