BUG#21077: Possible crash caused by invalid sequence of handler::* calls:                                                
The crash was caused by invalid sequence of handler::** calls:                                                           
  ha_smth->index_init();                                                                                                 
  ha_smth->index_next_same(); (2)                                                                                        
(2) is an invalid call as it was not preceeded by any 'scan setup' call
like index_first() or index_read(). The cause was that QUICK_SELECT::reset()
didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten,
and quick select might attempt to continue reading the range, which would
result in the above mentioned invalid sequence of handler calls.

5.x versions are not affected by the bug - they already have the missing
"range=NULL" clause.                                                    
                                                       

into  moonbone.local:/work/tmp_merge-4.1-opt-mysql

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1

  Corrected typo

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1

  Man page for mysqld command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

into  rakia.(none):/home/kgeorge/mysql/autopush/B20792-4.1-opt

into  rakia.(none):/home/kgeorge/mysql/autopush/B20792-4.1-opt

When processing aggregate functions all tables values are reset
to NULLs at the end of each group. 
When doing that if there are no rows found for a group
the const tables must not be reset as they are not recalculated 
by do_select()/sub_select() for each group.

into  rakia.(none):/home/kgeorge/mysql/autopush/B21019-4.1-opt

Too many cursors (more than 1024) could lead to memory corruption.
This affects both, stored routines and C API cursors, and the
threshold is per-server, not per-connection.  Similarly, the
corruption could happen when the server was under heavy load
(executing more than 1024 simultaneous complex queries), and this is
the reason why this bug is fixed in 4.1, which doesn't support
cursors.

The corruption was caused by a bug in the temporary tables code, when
an attempt to create a table could lead to a write beyond allocated
space.  Note, that only internal tables were affected (the tables
created internally by the server to resolve the query), not tables
created with CREATE TEMPORARY TABLE.  Another pre-condition for the
bug is TRUE value of --temp-pool startup option, which, however, is a
default.

The cause of a bug was that random memory was overwritten in
bitmap_set_next() due to out-of-bound memory access.

 When optimizing conditions like 'a = <some_val> OR a IS NULL' so that they're
 united into a single condition on the key and checked together the server must 
 check which value is the NULL value in a correct way : not only using ->is_null 
 but also check if the expression doesn't depend on any tables referenced in the 
 current statement. 
 This additional check must be performed because that optimization takes place 
 before the actual execution of the statement, so if the field was initialized 
 to NULL from a previous statement the optimization would be applied incorrectly.

into  lamia.home:/home/tkatchaounov/autopush/4.1-bug-20954

The problem was in that opt_sum_query() replaced MIN/MAX functions
with the corresponding constant found in a key, but due to imprecise
representation of float numbers, when evaluating the where clause,
this comparison failed.

When MIN/MAX optimization detects that all tables can be removed,
also remove all conjuncts in a where clause that refer to these
tables. As a result of this fix, these conditions are not evaluated
twice, and in the case of float number comparisons we do not discard
result rows due to imprecise float representation.

As a side-effect this fix also corrects an unnoticed problem in
bug 12882.

into  trift2.:/M41/push-4.1

into  trift2.:/M41/push-4.1

 - Send confusing output to /dev/null

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1-new

  Filter out strange control characters, messes up logs

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

  Add implementations of Item_func_{nop,not}_all::neg_transformer

into  mysql.com:/home/hf/work/mysql-4.1.19983

for class Item_func_trim. 
For 4.1 it caused wrong output for EXPLAIN EXTENDED commands
if expressions with the TRIM function of two arguments were used.
For 5.0 it caused an error message when trying to select
from a view with the TRIM function of two arguments.
This unexpected error message was due to the fact that the
print method for the class Item_func_trim was inherited from
the class Item_func. Yet the TRIM function does not take a list
of its arguments. Rather it takes the arguments in the form:
  [{BOTH | LEADING | TRAILING} [remstr] FROM] str) |
  [remstr FROM] str

 - backport patch from 5.0
 - "table" can be NULL in temporary fields used for type conversion

  Added new "mysql_explain_log" man page
  Added missing install of "myisam_ftdump" man page
  Added missing install of "mysqlman" man page

into  moonbone.local:/work/tmp_merge-4.1-opt-mysql

into  moonbone.local:/work/tmp_merge-4.1-opt-mysql

Please use "ul" when merging this changeset to 5.0.

1) When initializing a boolean variable, do not use string representations '"false"' and '"true"' 
    but rather the boolean values 'false' and 'true'.
2) Add the module to the various Windows description files.

In 5.0, this is already solved, so that is a null-merge ("ul").

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my41-1.2461

  Command "ndb_mgm" is an optional tool, and should only be in "ndb-tools" package (bug#21058)

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

to avoid the potential security problem.
(see bug #15195: Security Breach with MERGE table)

into  rakia.(none):/home/kgeorge/mysql/autopush/B17212-4.1-opt

into  mysql.com:/home/hf/work/mysql-4.1.16017