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

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

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

  review comment 2, atleast 1 signal need for test prg

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

  review comment
  if some tcp-transporter has data, then do select with timeout 0

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

  Make sure that data can not e left lingering in receive buffer

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

into  vajra.(none):/opt/local/work/mysql-4.1-runtime

for a query over an empty table right after its creation. 
The crash is the result of an attempt made by JOIN::optimize to evaluate
the WHERE condition when no records have been actually read.
The added test case can reproduce the crash only with InnoDB tables and
only with 5.0.x.
 

statement from a UNION query with ORDER BY an expression containing
RAND().
The crash happened because the global order by list in the union query
was not re-initialized for execution.
(Local order by lists were re-initialized though).

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work

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

 - Queries in the query cache are identified by the individual 
   characters in the query statement, the current database and 
   the current environment expressed as a set of system variable
   flags.
 - Since the set of environment flags didn't properly describe the
   current environment unexpected results were returned from the 
   query cache.
 - Query cache is now cleared when the variable ft_boolean_syntax is 
   updated.
 - An identification flag for the variable default_week_format is 
   added to the query cache record.
 
Thanks to Martin Friebe who has supplied significant parts of this patch.

into  dev3-221.dev.cn.tlan:/home/ngb/mysql/mysql-4.1/mysql-4.1-ndb

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

When checking for applicability of join cache
we must disable its usage only if there is no
temp table in use.
When a temp table is used we can use join
cache (and it will not make the result-set 
unordered) to fill the temp table. The filesort() 
operation is then applied to the data in the temp 
table and hence is not affected by join cache
usage.
Fixed by narrowing the condition for disabling 
join cache to exclude the case where temp table
is used.

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work

The generic string to int conversion was used by the Item_func_signed and
the Item_func_unsigned classes to convert DATE/DATETIME values to the
SIGNED/UNSIGNED type. But this conversion produces wrong results for such
values.

Now if the item which result has to be converted can return its result as
longlong then the item->val_int() method is used to allow the item to carry
out the conversion itself and return the correct result.
This condition is checked in the Item_func_signed::val_int() and the
Item_func_unsigned::val_int() functions.

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work

some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
list contained constant expressions.

This happened because the results of constant expressions were not put
in the temporary table used for duplicate elimination. In fact a constant
item from the GROUP BY list of a ROLLUP query can be replaced for an
Item_null_result object when a rollup row is produced . 

Now the JOIN::rollup_init function wraps any constant item referenced in
the GROYP BY list of a ROLLUP query into an Item_func object of a special
class that is never detected as constant item. This ensures creation of
fields for such  constant items in temporary tables and guarantees right
results when the result of the rollup operation first has to be written
into a temporary table, e.g. in the cases when duplicate elimination is
required.  

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt

into  gshchepa.loc:/home/uchum/work/bk-trees/mysql-4.1-opt-13191

INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
"Can't find record in ..." if we are inserting into
InnoDB table unique index of partial key with
underlying UTF-8 string field.

This error occurs because INSERT...ON DUPLICATE uses a wrong
procedure to copy string fields of multi-byte character sets
for index search.

This bug occurs when error message length exceeds allowed limit: my_error()
function outputs "%s" sequences instead of long string arguments.

Formats like %-.64s are very common in errmsg.txt files, however my_error()
function simply ignores precision of those formats.

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines

into  trift-lap.fambruehe:/MySQL/M41/push-4.1

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work

into  mysql.com:/home/ram/work/b27515/b27515.4.1

into  mysql.com:/home/ram/work/b27515/b27515.4.1

into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/41

into  debian.(none):/M41/push-4.1

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build-work