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.

into mysql.com:/M40/mysql-4.0

  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.

  Call mark_as_null_row in join_read_const and join_read_system.

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

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

into serg.mylan:/usr/home/serg/Abk/mysql-4.0

insertion of new records partially failed. It would get logged because of the
logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back
in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled
back on failure, even for non-transactional tables. (Bug #6682)
(Original fix reimplemented after review by Serg and Guilhem.)

two-line fix for BUG#6732 "FLUSH TABLES WITH READ LOCK + COMMIT makes next FLUSH...LOCK hang forever"
(originally reported as "second run of innobackup hangs forever and can even hang server").
Plus testcase for the bugfix and comments about global read locks.

  srv_lock_timeout_and_monitor_thread(): write to srv_monitor_file
  only if --innodb_status_file=1

(Cleanups and better bug fixes)

into mysql.com:/home/timka/mysql/src/4.0-master

into mysql.com:/space/bk/b6148-mysql-4.0

slave SQL thread is started.

to run the standard tests with "--force" (default, can be switched off).

into serg.mylan:/usr/home/serg/Abk/mysql-4.0

  bug#6705 - (+trunc1* +trunc2*)
fulltext.test, fulltext.result:
  bug#6705

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

When mysqlbinlog prints LOAD DATA INFILE, let it print the thread id. Some customer would have benefited
much from this in his recovery. All this change does is adding one commented (#) line before the LOAD DATA
command, so it is quite innocuous.

  Fix InnoDB bug #6287: if one uses INSERT IGNORE to insert several rows at a time, and the first inserts are ignored because of a duplicate key collision, then InnoDB in a replication slave assigns AUTO_INCREMENT values 1 bigger than in the master

values for too big argument".

Added range checking for from_unixtime() argument, cleaned up code 
a bit.

were stopping at docid 0xffffffff