Build gcc.o as a small library, instead of passing .cpp sources to the
linker command (causes problems with parallel make on Solaris).

This fix is for 4.1. In 5.0 and up a different fix is used.


ndb/config/common.mk.am:
  Build gcc.o as a small library, instead of passing .cpp sources to the
  linker command (causes problems with parallel make on Solaris).
ndb/config/type_ndbapitools.mk.am:
  Build gcc.o as a small library, instead of passing .cpp sources to the
  linker command (causes problems with parallel make on Solaris).
ndb/src/common/portlib/Makefile.am:
  Build gcc.o as a small library, instead of passing .cpp sources to the
  linker command (causes problems with parallel make on Solaris).
ndb/src/kernel/Makefile.am:
  Build gcc.o as a small library, instead of passing .cpp sources to the
  linker command (causes problems with parallel make on Solaris).

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

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.


mysql-test/r/ctype_ucs2_def.result:
  Adding test cast
mysql-test/t/ctype_ucs2_def-master.opt:
  Adding test case
mysql-test/t/ctype_ucs2_def.test:
  Adding test case
sql/mysqld.cc:
  Don't clear default_collation_name when processing 
  --character-set-server if collation has already
  been specified using --collation-server

--with-collation worked only on the server side.
Client side ignored this argument, so collation_connection
was not properly set (remained latin1_swedish_ci).



sql-common/client.c:
  - Take into account MYSQL_DEFAULT_COLLATION_NAME if
  character set is not set using mysql_option(), to
  honor --with-collation argument to configure.
  - Use default collation for the character set when it's
  not set using mysql_option().

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


myisam/mi_unique.c:
  Fix for bug #20709: Collation not used in group by on 4.1.    
  
  myisam/mi_uniue.c:mi_check_unique() should skip trailing spaces comparing 
  TEXT and VARTTEXT key segments.
    
  Example: assume, we have a 'char(200) collate utf8_unicode_ci' field,
  there are two records with _utf8"0x65" and _utf8"0xC3A9" characters;
  these values are equal according
  to the utf8_unicode_ci collation, but two 600 byte length corresponding keys:  
  "0x65<0x20 repeats 599 times>" and "0xC3A9<0x20 repeats 598 times>" are not    
  equal if we count trailing spaces and it may cause inconsequent behavior.
  
  So, let's pass 1 as the skip_end_space parameter value to the mi_compare_text()
  function for proper TEXT and VARTTEXT key segments comparison.
mysql-test/r/ctype_utf8.result:
  Fix for bug #20709: Collation not used in group by on 4.1.    
    - test results.
mysql-test/t/ctype_utf8.test:
  Fix for bug #20709: Collation not used in group by on 4.1.    
    - test case.

BitKeeper/deleted/.del-bug20328.test:
  Delete: mysql-test/t/bug20328.test
BitKeeper/deleted/.del-bug20328.result:
  Delete: mysql-test/r/bug20328.result

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.


myisam/mi_update.c:
  Every myisam function that updates myisam table must end with
  call to _mi_writeinfo(). If operation (second param of
  _mi_writeinfo()) is not 0 it sets share->changed to 1, that is
  flags that data has changed. If operation is 0, this function
  equals to no-op in this case.
  
  mi_update() must always pass !0 value as operation, since even if
  there is no index change there could be data change.

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


sql/mysqld.cc:
  Add else case to set "lower_case_file_system" also when lower_case_table_names are 1

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


mysql-test/t/mysqlbinlog.test:
  Auto merged

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


mysql-test/r/grant.result:
  Addition to test case for bug#7391:
  - Added grant statement to trigger this problem in 4.1.
  - Fixed error messages.
mysql-test/t/grant.test:
  Addition to test case for bug#7391:
  - Added grant statement to trigger this problem in 4.1.
  - Fixed error messages.
sql/sql_update.cc:
  check_grant() accepts number of tables (in table list) to be checked
  in 5-th param. For this particular check 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


sql/set_var.cc:
  Auto merged

set.

(Ramil's patch, recreated.)


heap/hp_delete.c:
  Reset info->lastkey_len for further heap_rnext/heap_rprev calls.
mysql-test/r/heap_btree.result:
  Test for bug #9719: DELETE with WHERE on HEAP table just deletes first 
  row of matched set.
mysql-test/t/heap_btree.test:
  Test for bug #9719: DELETE with WHERE on HEAP table just deletes first 
  row of matched set.

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


sql/item_strfunc.cc:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/sql_parse.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged

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


client/mysql.cc:
  Auto merged

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


client/mysqltest.c:
  Init start_lineno to 0 and set it back to zero before comparing result file.

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


configure.in:
  Auto merged

  Corrected typo


configure.in:
  Corrected typo

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


configure.in:
  Auto merged
scripts/make_binary_distribution.sh:
  Auto merged
support-files/mysql.spec.sh:
  SCCS merged

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


configure.in:
  Man page for mysqld command move to section 8 (bug#21220)
man/Makefile.am:
  Man page for mysqld command move to section 8 (bug#21220)

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


scripts/make_binary_distribution.sh:
  Man page for "mysqld" command move to section 8 (bug#21220)

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


support-files/mysql.spec.sh:
  Man page for "mysqld" command move to section 8 (bug#21220)

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


sql/sql_select.cc:
  Auto merged

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


sql/sql_select.cc:
  Auto merged

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.


mysql-test/r/subselect2.result:
  * Bug #20792: Incorrect results from aggregate subquery
   - test suite for the bug. This is dependent on InnoDB despite
     the fact that the bug and the fix are not InnoDB specific.
     This is because of the table flag HA_NOT_EXACT_COUNT.
     When this flag is off (as in MyISAM) both t2 and t3 become of
     join type 'system' as they are estimated to have 1 record and
     and this statistics can be trusted (according to the absence of
     HA_NOT_EXACT_COUNT).
mysql-test/t/subselect2.test:
  * Bug #20792: Incorrect results from aggregate subquery
   - test suite for the bug
sql/sql_select.cc:
  * Bug #20792: Incorrect results from aggregate subquery
   - when clearing results if there are not rows found for group
     the const tables must not be reset as they are not recalculated
     for each group.

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


sql/sql_select.cc:
  Auto merged
mysql-test/r/select.result:
  SCCS merged
mysql-test/t/select.test:
  SCCS merged

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.


mysys/my_bitmap.c:
  Local 'bitmap_size' is measured in bytes, no need to multiply it by 8.
sql/sql_select.cc:
  Clear the temp_pool_slot bit only if we have set it previously.