didn't work as expected: collation_server was set not to xxx,
but to the default collation of character set "yyy".
    
With different argument order it worked as expected:
mysqld --character-set-server=yyy --collation-server=yyy 
    
Fix:
initializate default_collation_name to 0
when processing --character-set-server
only if --collation-server has not been specified
in command line.

myisam/mi_uniue.c:mi_check_unique() should skip trailing spaces comparing 
TEXT and VARTTEXT key segments.

into  may.pils.ru:/home/svoj/devel/mysql/BUG20060/mysql-4.1

Problem described in this bug report affects MyISAM tables only.

Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.

This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.

into  mysql.com:/usr/home/bar/mysql-4.1.b19741

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1

 - Backport patch from 5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1

           privileges

This problem is 4.1 specific. It doesn't affect 4.0 and was fixed
in 5.x before.

Having any mysql user who is allowed to issue multi table update
statement and any column/table grants, allows this user to update
any table on a server (mysql grant tables are not exception).

check_grant() accepts number of tables (in table list) to be checked
in 5-th param. While checking grants for multi table update, number
of tables must be 1. It must never be 0 (actually we have
DBUG_ASSERT(number > 0) in 5.x in grant_check() function).

into  zippy.cornsilk.net:/home/cmiller/work/mysql/m41-maint--07OBQ

set.

(Ramil's patch, recreated.)

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-4.1-maint_bug20721

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

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

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

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

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into  anubis.greendragongames.com:/home/greenman/workspace-mysql/mysql/pending/bug-4.1-19364

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1

 - Init start_lineno to 0

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.

 - Modify test case to workaround the test tool problem
 - (Null merge into 5.0)