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().

after merge.

Concurrent read and update of privilege structures (like simultaneous
run of SHOW GRANTS and ADD USER) could result in server crash.

Ensure that proper locking of ACL structures is done.

No test case is provided because this bug can't be reproduced
deterministically.

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

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

into  hundin.mysql.fi:/home/jani/mysql-5.0merge_4_1_2nd

into  hundin.mysql.fi:/home/jani/mysql-5.0merge_4_1_2nd

into  mysql.com:/space/pekka/ndb/version/my50-work

The reason of the bug is in that `get_var_with_binlog' performs missed
assingment of
the variables as side-effect. Doing that it eventually calls
`free_underlaid_joins' to pass as an argument `thd->lex->select_lex' of the lex
which belongs to the user query, not 
to one which is emulated i.e SET @var1:=NULL.


`get_var_with_binlog' is refined to supply a temporary lex to sql_set_variables's stack.

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

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

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