reading tables in "complex" SQL statements. If inserts happen in a
table being read, the statements have no serialization order and the
change can therefore not be reproduced on the slave.


sql/sql_update.cc:
  Switching to using T_READ_NO_INSERT when the binlog is used.
sql/sql_yacc.yy:
  Switching to using T_READ_NO_INSERT when the binlog is used.

  Made the default --mail address to be <build@mysql.com>.


Build-tools/Bootstrap:
  Made the default --mail address to be <build@mysql.com>.

This happened only if my_write() couldn't write even one byte.
I cannot easily add a .test for this, but I tested by hand before and after the change.


mysys/my_write.c:
  Monty and I could not find a reason why a write should not wait for free disk space
  (if disk is full) because it could not write at least one byte; doing so certainly
  corrupts tables. my_pwrite() and my_fwrite() don't test for -1, so no problem.

   build (to make the test suite pass)


BUILD/compile-dist:
  - enable "with-extra-charsets=complex" for the distribution build
    (to make the test suite pass)

official binary builds for Linux that are built against a static glibc with
a 128k thread stack size limit can be compiled with a default that doesn't
result in a harmless (but oft-misunderstood) warning message. (Bug #6226)


include/my_pthread.h:
  Allow DEFAULT_THREAD_STACK to be set via -DDEFAULT_THREAD_STACK=...

sql/set_var.cc:
  Make query_cache_wlock_invalidate visible in SHOW VARIABLES

  ChangeLog, too (to be more exact when tagging a release that's based on a
  merge ChangeSet)


Build-tools/Bootstrap:
  - include merge ChangeSets into the ChangeLog, too (to be more exact when
    tagging a release that's based on a merge ChangeSet)

into sergbook.mysql.com:/usr/home/serg/Abk/mysql-4.0

Build-tools/Bootstrap:
  - Use BUILD/compile-dist instead of compile-pentium-max
  - some minor cleanups

into mysql.com:/home/dlenev/src/mysql-4.0-bg7297

the Epoch". (With after review fixes).


mysql-test/r/func_time.result:
  Added test for bug #7515 "from_unixtime(0) now returns NULL instead of
  the Epoch".
mysql-test/t/func_time.test:
  Added test for bug #7515 "from_unixtime(0) now returns NULL instead of
  the Epoch".
sql/item_timefunc.cc:
  Item_func_from_unixtime:
   from_unixtime(0) should return Epoch instead of NULL.
sql/item_timefunc.h:
  Item_func_from_unixtime:
   - Removed unused method definition.
   - fix_length_and_dec() should set maybe_null to true since now
     from_unixtime() can return NULL even in case when none of its
     arguments is NULL.

  Fix the previous bug fix: dropping a table with FOREIGN KEY checks running on it caused a cascade of failed drops while the foreign key check was waiting for a lock


innobase/row/row0mysql.c:
  Fix the previous bug fix: dropping a table with FOREIGN KEY checks running on it caused a cascade of failed drops while the foreign key check was waiting for a lock

  Fix bug: if we dropped a table where an INSERT was waiting for a lock to check a FOREIGN KEY constraint, then an assertion would fail in lock_reset_all_on_table(), since that operation assumes no waiting locks on the table or its records
row0mysql.c:
  Fix bug: InnoDB failed to drop a table in the background drop queue if the table was referenced by a foreign key constraint


innobase/row/row0mysql.c:
  Fix bug: InnoDB failed to drop a table in the background drop queue if the table was referenced by a foreign key constraint
innobase/row/row0ins.c:
  Fix bug: if we dropped a table where an INSERT was waiting for a lock to check a FOREIGN KEY constraint, then an assertion would fail in lock_reset_all_on_table(), since that operation assumes no waiting locks on the table or its records

sql/mysqld.cc:
  A fix (bug #5652: [patch] tcpwrapper support is broken on systems using an unmodified tcpwrapper).
  Wrapper for fromhost, hosts_access, eval_client has been removed.

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

mysql-test/r/func_str.result:
  result for test case for a bug in QUOTE() (Bug #7495)
mysql-test/t/func_str.test:
  test case for a bug in QUOTE() (Bug #7495)
sql/item_strfunc.cc:
  a better fix for a QUOTE() bug (Bug #7495)

to behave well on 5.0 tables (well now you can't use tables from 4.1
and 5.0 with 4.0 because former use utf8, but still it is nice to have
similar code in acl_init() and replace_user_table()).
This also will make such GRANTs working in 5.0 (they are broken now).


mysql-test/r/grant.result:
  Added test for GRANT which manipulates user limits.
mysql-test/t/grant.test:
  Added test for GRANT which manipulates user limits.

mysql-test/r/func_str.result:
  A result for test case for the bug #7495 involving either LTRIM() 
  or TRIM() within QUOTE() function.
mysql-test/t/func_str.test:
  A test case for the bug #7495 involving either LTRIM() or TRIM() 
  within QUOTE() function.
sql/item_strfunc.cc:
  Changes for LTRIM() and TRIM() functions that aleviate the bug  
  entirely.

  If AUTOCOMMIT=1, do not acquire an InnoDB table lock in LOCK TABLES; this makes porting of old MyISAM applications to InnoDB easier, since in that mode InnoDB table locks caused deadlocks very easily


sql/ha_innodb.cc:
  If AUTOCOMMIT=1, do not acquire an InnoDB table lock in LOCK TABLES; this makes porting of old MyISAM applications to InnoDB easier, since in that mode InnoDB table locks caused deadlocks very easily

  Put back accidentally removed undef and remove a debug def


innobase/os/os0file.c:
  Put back accidentally removed undef and remove a debug def

  Fix InnoDB bug: on HP-UX, with a 32-bit binary, InnoDB was only able to read or write <= 2 GB files; the reason was that InnoDB treated the return value of lseek() as a 32-bit integer; lseek was used on HP-UX-11 as a replacement for pread() and pwrite() because HAVE_BROKEN_PREAD was defined on that platform


innobase/os/os0file.c:
  Fix InnoDB bug: on HP-UX, with a 32-bit binary, InnoDB was only able to read or write <= 2 GB files; the reason was that InnoDB treated the return value of lseek() as a 32-bit integer; lseek was used on HP-UX-11 as a replacement for pread() and pwrite() because HAVE_BROKEN_PREAD was defined on that platform

  Increment from 4.0.23 to 4.0.24


configure.in:
  Increment from 4.0.23 to 4.0.24

into ltantony.rdg.cyberkinetica.homeunix.net:/usr/home/antony/work/bug7391.4

  Add in missing privilege checks. 
  Tests for the privileges.


mysql-test/r/grant.result:
  Bug#7391 - Multi-table UPDATE security regression
    Tests column, table and db level access
mysql-test/t/grant.test:
  Bug#7391 - Multi-table UPDATE security regression
    Tests column, table and db level access
sql/sql_update.cc:
  Bug#7391 - Multi-table UPDATE security regression
    Add in missing privilege checks.

into mysql.com:/M40/mysql-4.0

mysql-test/mysql-test-run.sh:
  Backport an improvement from 4.1: If the tool is run with '--force', give a list of all test cases that failed at the end.
  This is essential for automated analysis of the build logs file.

mysql-test/r/update.result:
  moved drop statement
mysql-test/t/update.test:
  moved drop statement

mysql-test/r/update.result:
  test results
mysql-test/t/update.test:
  bug test

even with zero month and day" aka "Date decoding trouble"

Two digit year should be interpreted correctly as year in 20th or 21st
century even with zero month and day. Only exception should be zero date
'00-00-00' or '00-00-00 00:00:00'.


mysql-test/r/type_datetime.result:
  Added test for bug #7297 "Two digit year should be interpreted correctly
  even with zero month and day"
mysql-test/t/type_datetime.test:
  Added test for bug #7297 "Two digit year should be interpreted correctly
  even with zero month and day"
sql/time.cc:
  str_to_TIME(): Two digit year should be interpreted correctly as year
  in 20th or 21st century even with zero month and day. Only exception 
  should be zero date '00-00-00' or '00-00-00 00:00:00'.

  dict_load_table(): detect the new table format of MySQL 5.0.3


innobase/dict/dict0load.c:
  dict_load_table(): detect the new table format of MySQL 5.0.3

into mysql.com:/dbdata/psergey/mysql-4.0-bug6976

In Item_ref::Item_ref set maybe_null (and other fields fix_fields sets) to be the 
same as in (*ref), because Item_ref::fix_fields() will not be called.  Previously 
maybe_null was 0 always and this produced a bogus state where 
maybe_null==0 && is_null() == true 
which broke evaluation for some upper-level Items, like AND and OR.


mysql-test/r/group_by.result:
  Test for BUG#6976
mysql-test/t/group_by.test:
  Test for BUG#6976
sql/item.cc:
  Comment added
sql/item.h:
  Fix for BUG#6976:
    in Item_ref::Item_ref(Item**...) fix all fields because fix_fields() will not be called.

  Call mark_as_null_row in join_read_const and join_read_system.


mysql-test/r/multi_update.result:
  Testcase for BUG#5837
mysql-test/t/multi_update.test:
  Testcase for BUG#5837
sql/table.h:
  Added comments

into hundin.mysql.fi:/home/marko/k/mysql-4.0

  Fix for the 0xA0 character problem in the InnoDB FOREIGN KEY parser: if my_isspace() treats 0xA0 as space, then let InnoDB do the same; this might break some multi-byte charset id's, though for big5, ujis, sjis this seems not to change the current behavior (I checked the tables in /share/charsets); this fix must NOT be merged to 4.1 because in 4.1 everything is in UTF-8


sql/ha_innodb.cc:
  Fix for the 0xA0 character problem in the InnoDB FOREIGN KEY parser: if my_isspace() treats 0xA0 as space, then let InnoDB do the same; this might break some multi-byte charset id's, though for big5, ujis, sjis this seems not to change the current behavior (I checked the tables in /share/charsets); this fix must NOT be merged to 4.1 because in 4.1 everything is in UTF-8
innobase/dict/dict0dict.c:
  Fix for the 0xA0 character problem in the InnoDB FOREIGN KEY parser: if my_isspace() treats 0xA0 as space, then let InnoDB do the same; this might break some multi-byte charset id's, though for big5, ujis, sjis this seems not to change the current behavior (I checked the tables in /share/charsets); this fix must NOT be merged to 4.1 because in 4.1 everything is in UTF-8
innobase/include/dict0dict.h:
  Fix for the 0xA0 character problem in the InnoDB FOREIGN KEY parser: if my_isspace() treats 0xA0 as space, then let InnoDB do the same; this might break some multi-byte charset id's, though for big5, ujis, sjis this seems not to change the current behavior (I checked the tables in /share/charsets); this fix must NOT be merged to 4.1 because in 4.1 everything is in UTF-8

  srv_printf_innodb_monitor(): Removed extraneous rewind() call.
  The caller of this function calls rewind() if necessary.
  In this way, we avoid rewind()ing stderr in
  srv_lock_timeout_and_monitor_thread().


innobase/srv/srv0srv.c:
  srv_printf_innodb_monitor(): Removed extraneous rewind() call.
  The caller of this function calls rewind() if necessary.
  In this way, we avoid rewind()ing stderr in
  srv_lock_timeout_and_monitor_thread().