- correction of backport error

- make sure to disable bulk insert when check for duplicate key is needed


mysql-test/r/ndb_loaddatalocal.result:
  New BitKeeper file ``mysql-test/r/ndb_loaddatalocal.result''
mysql-test/t/ndb_loaddatalocal.test:
  New BitKeeper file ``mysql-test/t/ndb_loaddatalocal.test''

corrupt
  - add infinite retry on drop table temporary error

- always calculate max log level on node start
- send event subscribe uncond


ndb/src/mgmsrv/Services.cpp:
  Bug #20336 CLUSTERLOG commands have no effect
  - always send log level update

ndb/src/kernel/blocks/cmvmi/Cmvmi.cpp:
  Bug #20336 CLUSTERLOG commands have no effect
  - with signal sender the clock issuing the command and the revceiver of the events are not the same
ndb/src/mgmsrv/MgmtSrvr.cpp:
  Bug #20336 CLUSTERLOG commands have no effect
  - make sure to actually send the update to ndb nodes, and wait for the reply
ndb/src/mgmsrv/Services.cpp:
  Bug #20336 CLUSTERLOG commands have no effect
  - make sure to compute max every time for log level

    ndb: ndb_waiter disconnect/reconnect on get status error


ndb/src/mgmapi/mgmapi.cpp:
  ndb: added some missing error codes to mgmapi
ndb/tools/waiter.cpp:
  ndb: ndb_waiter disconnect/reconnect on get status error

- not having lock can cause "block number list" to become corrupt => crash
- also may result in 2 threads receiving same block no => possble cause of
Bug #13987 Cluster: Loss of data nodes can cause high CPU usage from ndb_mgmd


ndb/src/mgmsrv/MgmtSrvr.cpp:
  ndb: added missing lock of mutex

into  poseidon.ndb.mysql.com:/home/tomas/mysql-4.1


support-files/mysql.spec.sh:
  Auto merged

- invalidate ndb dict cache on cluster disconnect (ClusterMgr.cpp)
- add check for correct frm on external lock when table cache is found invalid


ndb/include/ndbapi/ndb_cluster_connection.hpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ClusterMgr.cpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ClusterMgr.hpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/DictCache.cpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/DictCache.hpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/TransporterFacade.hpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ndb_cluster_connection.cpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ndb_cluster_connection_impl.hpp:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
sql/ha_ndbcluster.cc:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
mysql-test/r/ndb_autodiscover3.result:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
mysql-test/t/ndb_autodiscover3.test:
  Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail

into  mysql.com:/home/mysql-4.1-10418

  Compile in all character sets in Max (bug#14918)


support-files/mysql.spec.sh:
  Compile in all character sets in Max (bug#14918)

into  mysql.com:/usr/home/ram/work/4.1.b18501


sql/item_timefunc.cc:
  Auto merged

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


support-files/mysql.spec.sh:
  Auto merged

load_file() string-function should return NULL rather than throw an error if
the file doesn't exist, as per the manual.


mysql-test/t/outfile.test:
  expect NULL rather than error if file given to load_file() doesn't exist
mysql-test/t/func_str.test:
  show that load_file() will return NULL rather than throw an error
  if file doesn't exist
mysql-test/r/outfile.result:
  expect NULL rather than error if file given to load_file() doesn't exist
mysql-test/r/func_str.result:
  expect NULL rather than error if file given to load_file() doesn't exist
sql/item_strfunc.cc:
  load_file() should return NULL as per the docs if file not found,
  rather than throw an error

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

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


sql/item_func.cc:
  Auto merged

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.



mysql-test/r/having.result:
  Added a test case for bug #14927.
mysql-test/t/having.test:
  Added a test case for bug #14927.
sql/sql_lex.cc:
  Fixed bug #14927.
  Initialized fields for having conditions in  st_select_lex::init_query().
sql/sql_lex.h:
  Fixed bug #14927.
  Added a field to restore having condititions for execution in SP and PS.
sql/sql_prepare.cc:
  Fixed bug #14927.
  Added code to restore havinf conditions for execution in SP and PS.
sql/sql_select.cc:
  Fixed bug #14927.
  Performed evaluation of constant expressions in having clauses.
  If the having condition contains a constant conjunct that is always false
  an empty result set is returned after the optimization phase.
  In this case the corresponding EXPLAIN command now returns 
  "Impossible HAVING" in the last column.

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

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

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

mysql-test/r/func_misc.result:
  Update the result.

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

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

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


mysql-test/r/innodb_mysql.result:
  Testcase for BUG16798
mysql-test/t/innodb_mysql.test:
  Testcase for BUG16798
sql/sql_select.cc:
  BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions 
  In merge_key_fields() don't call val->is_null() if the value of val is not known.

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.


mysql-test/r/rpl_user_variables.result:
  results changed
mysql-test/t/rpl_user_variables.test:
  a problematic query to be binlogged is added
sql/item_func.cc:
  BUG#19136: Crashing log-bin and uninitialized user variables
  
  The reason of the bug is in that how `get_var_with_binlog' performs missed
  assingment of the variables: `free_underlaid_joins' gets as an argument `thd->lex->select_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

into  polar.kitebird.com:/src/extern/MySQL/bk/mysql-4.1

  Delete: Docs/changelog-4.1.xml


BitKeeper/deleted/.del-changelog-4.1.xml~8aa496ebed09d868:
  Delete: Docs/changelog-4.1.xml

into  polar.kitebird.com:/src/extern/MySQL/bk/mysql-4.1

  Delete: Docs/changelog-4.0.xml


BitKeeper/deleted/.del-changelog-4.0.xml~8f56ee8a913e848b:
  Delete: Docs/changelog-4.0.xml

into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-4.1

TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column


mysql-test/r/date_formats.result:
  Added test case for Bug#11324,
  "TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column"
mysql-test/t/date_formats.test:
  Added test case for Bug#11324,
  "TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column"

mysql-test/r/date_formats.result:
  Added test cases for Bug#11326
mysql-test/t/date_formats.test:
  Added test cases for Bug#11326

into  a193-229-222-105.elisa-laajakaista.fi:/home/my/bk/mysql-4.1

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

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