always initialized. (Bug #5569)

into mysql.com:/home/jimw/my/mysql-4.0-clean

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

macros.

It does not fixes any bugs in 4.0. But it prevents from future error in
any bugfixes that may use these macros. Also after merging into 4.1 tree
this cleanup will fix bug #7884 "Able to add invalid unique index on
TIMESTAMP prefix".

into mysql.com:/space/my/mysql-4.0

set to a negative value. (Bug #7700)

  Mac OS X PKGs with Do-pkg

into mysql.com:/home/jimw/my/mysql-4.0-clean

it has been specified. (Bug #7347)

  Fix a theoretical hang over the adaptive hash latch in InnoDB if one runs INSERT ... SELECT ... (binlog not enabled), or a multi-table UPDATE or DELETE, and only the read tables are InnoDB type, the rest are MyISAM; this also fixes bug #7879 for InnoDB type tables

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

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

reported by Javier Fernandez-Sanguino Pena
and Debian Security Audit Team (http://www.debian.org/security/audit)

case will be added to client_test in 4.1

open interface for setting the "delete-on-close" flag.

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

mysql_admin_table() attempted to write to a vio which was 0. I could have fixed mysql_admin_table()
but fixing my_net_write() looked more future-proof.

  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.

   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)

  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

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

the Epoch". (With after review fixes).

  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

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

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

  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