"EE_ error codes (EE_DELETE, EE_WRITE) end up in the binlog, making slave stop".
The problem was that during execution of the command on the master, an error
can occur (for example, not space left on device, then mysqld waits and when
there is space it completes successfully: so finally it worked but the error
EE_WRITE remains in thd->net.last_errno and thd->net.last_error).
To know if finally the command succeeded, we test the 'error' variable in
every place, and if it shows no failure we reset thd->net.last_err* using
the function THD::clear_error() which is backported from 4.1.
A new test to see if now only real errors get to the binlog (note: the test
uses "rm").

Also a bit of memory free/alloc saving in log_event.cc (do not free the whole
mem_root after every query in the slave SQL thread: we can keep the initial
block of it; which will be freed when the thread terminates).


sql/log_event.cc:
  In the slave SQL thread, it's a waste to free the initial block of the mem_root
  after every query. We can instead keep it. It will be freed when the thread
  terminates (in THD::~THD()).
sql/sql_acl.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_base.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_class.h:
  Backport of THD::clear_error() from 4.1:
  clears the error in thd->net.last_errno
sql/sql_db.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_delete.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_insert.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_parse.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_rename.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_table.cc:
  clear the error in thd->net.last_errno as there was no error
sql/sql_update.cc:
  clear the error in thd->net.last_errno as there was no error

Otherwise, if the previous run ended with a crash, and the PID was 1234,
and you have rebooted the machine and the new PID is 99 then in the PID
file you will have 9934.
Note: users of mysqld_safe did not have the problem because this script
deletes the PID file before starting mysqld.

into mysql.com:/home/mysql_src/mysql-4.0

The constructor of Rotate_log_event used when we are rotating our binlog or
relay log, should not assume that there is a nonzero THD available.
For example, when we are reacting to SIGHUP, the THD is 0.
In fact we don't need to use the THD in this constructor;
we can do like for Stop_log_event, and use the minimal Log_event
constructor.
If we were allowed to put Unix-specific commands in the testsuite,
I'd add a test for this (<sigh>).


sql/log.cc:
  A comment to warn that thd can be 0.
  The part about LOG_EVENT_FORCED_ROTATE_F is just to avoid segfault;
  this flag is already removed in 4.1 anyway.
sql/log_event.cc:
  A comment.
sql/log_event.h:
  The constructor of Rotate_log_event used when we are rotating our binlog or
  relay log, should not assume that there is a nonzero THD available.
  For example, when we are reacting to SIGHUP, the THD is 0.
  In fact we don't need to use the THD in this constructor;
  we can do like for Stop_log_event, and use the minimal Log_event
  constructor.
  This fixes BUG#2045 
  "Sending SIGHUP to mysqld crashes it if running with --log-bin"

into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.defweek


sql/mysqld.cc:
  Auto merged

New formats added for 'week()' function and 'default_week_format' option(4 - 7).
Next formats is supported now:
*Value* *Meaning*
  `0'     Week starts on Sunday; First Sunday of the year starts week 1.
  	  Week() returns 0-53.
  `1'     Week starts on Monday; Weeks numbered according to ISO 8601:1988.
	  Week() returns 0-53.
  `2'     Week starts on Sunday; First Sunday of the year starts week 1.
  	  Week() returns 1-53.
  `3'     Week starts on Monday; Weeks numbered according to ISO 8601:1988.
	  Week() returns 1-53.
  `4'     Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
	  Week() returns 0-53.
  `5'     Week starts on Monday;  First Monday of the year starts week 1.
  	  Week() returns 0-53.
  `6'     Week starts on Sunday; Weeks numbered according to ISO 8601:1988.
	  Week() returns 1-53.
  `7'     Week starts on Monday;  First Monday of the year starts week 1.
  	  Week() returns 1-53.


mysql-test/r/func_time.result:
  Test for 'default_week_format' option and 'week' function
mysql-test/t/func_time.test:
  Test for 'default_week_format' option and 'week' function
sql/item_timefunc.cc:
  WL#1175 more default_week_formats for iso compatibility
sql/mysql_priv.h:
  WL#1175 more default_week_formats for iso compatibility
sql/mysqld.cc:
  WL#1175 more default_week_formats for iso compatibility
sql/time.cc:
  WL#1175 more default_week_formats for iso compatibility

into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.pass


sql/sql_parse.cc:
  Auto merged

include/config-win.h:
  ULONGLONG_MAX definition added
include/my_global.h:
  comment about config-win.h added

into mysql.com:/home/kostja/mysql/mysql-4.0-root

into mysql.com:/home/mysql_src/mysql-4.0

we change THD::system_thread from a 'bool' to a bitmap to be able to
distinguish between delayed-insert threads and slave threads.
- Fix for BUG#1701 "Update from multiple tables" (one line in sql_parse.cc,
plus a new test rpl_multi_update.test). That's just adding an initialization.


sql/repl_failsafe.cc:
  comment to warn about this unused code
sql/slave.cc:
  Now thd->system_thread is a bitmap, not a bool.
sql/sql_class.h:
  'bool' for THD::system_thread is not accurate enough; sometimes we need
  to distinguish between delayed-insert threads and slave threads;
  so changing THD::system_thread to a bitmap (uint).
sql/sql_insert.cc:
  thd.system_thread is now a bitmap
sql/sql_parse.cc:
  We need to initialize thd->lex.select_lex.options in mysql_init_query();
  it's already initialized in dispatch_command() but replication calls
  mysql_parse() directly, thus bypassing dispatch_command().
  Not initing it here leads to a query influencing the next query,
  in the slave SQL thread.
  The initialization in dispatch_command() must be kept as this
  command uses the variable in tests, even when the command was not a
  query (i.e. when mysql_init_query() was not called).

into mysql.com:/home/kostja/mysql/mysql-4.0-1790

into mysql.com:/bk/mysql-4.0

VC++Files/InstallShield/4.0.XX-classic/String Tables/0009-English/value.shl:
  This should not be the product version; it must match Default.shl
VC++Files/InstallShield/4.0.XX-gpl/String Tables/0009-English/value.shl:
  This should not be the product version; it must match Default.shl
VC++Files/InstallShield/4.0.XX-pro/String Tables/0009-English/value.shl:
  This should not be the product version; it must match Default.shl

into mysql.com:/my/mysql-4.0

move bdb/innodb tests to right places


mysql-test/r/bdb.result:
  Update results after test changes
mysql-test/r/innodb.result:
  Update results after test changes
mysql-test/r/multi_update.result:
  Update results after test changes
mysql-test/t/bdb.test:
  Move bdb tests here
mysql-test/t/innodb.test:
  Move innodb test here
mysql-test/t/multi_update.test:
  move bdb/innodb tests to repective test
sql/mysqld.cc:
  Allow space in service names

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

if we failed to classify integer as datetime 
in Field_datetime::store().
Stylistic clean-ups.


sql/field.cc:
  Fix undeterministic behaviour of year check 
  if we failed to classify integer as datetime
  Stylistic clean-ups.

into mysql.com:/home/mysql_src/mysql-4.0

The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the
slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs
it also for check_binlog_magic().
This should fix all recently reported failures of the rpl_max_relay_size test in 4.1 and 5.0
(though the bug exists since 4.0, it showed up first in 5.0).


sql/slave.cc:
  Fix for BUG#2011 "rare race condition producing "binlog has bad magic number" error in slave".
  The problem was that when the slave SQL thread reads a hot relay log (hot = the one being written to by the
  slave I/O thread), it must have the LOCK_log. It already took it for read_log_event(), but needs
  it also for check_binlog_magic().

into gluh.mysql.r18.ru:/home/gluh/mysql-4.0.bugfssl

into mysql.com:/home/psergey/mysql-4.0

   "$1: unbound variable" error when no option was given


support-files/MacOSX/MySQL:
   - Suppress the annoying "$1: unbound variable" error when no option
     was given

into mysql.com:/home/mysql_src/mysql-4.0

into mysql.com:/home/psergey/mysql-4.0

BitKeeper/etc/logging_ok:
  Logging to logging@openlogging.org accepted

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

about it". Now numbers representing illegal timestamps are 
converted to 0 value if they are stored as timestamp or 
datetime. This behaviour is consistent with manual and with 
behaviour of string -> timestamp conversion.


mysql-test/r/type_datetime.result:
  Added test if ranges are checked during 
  integer, string -> timestamp conversion
mysql-test/r/type_timestamp.result:
  Added test if ranges are checked during 
  integer, string -> datetime conversion
mysql-test/t/type_datetime.test:
  Added test if ranges are checked during 
  integer, string -> datetime conversion
mysql-test/t/type_timestamp.test:
  Added test if ranges are checked during 
  integer, string -> timestamp conversion
sql/field.cc:
  Checks of month, day, hour, minute and second ranges were added
  to storing of integer into Field_datetime and Field_timestamp
  and so for integer -> datetime, timestamp conversion.

 SQL_BIG_RESULT used':
- BIT_AND now returns BIGINT UNSIGNED
- in case there were no matching rows BIT_AND returns 18446744073709551615 
(but not NULL), BIT_OR returns 0 (but not NULL). That's how Monty wants it
and how is described in our docs.




include/my_global.h:
  Added definition for ULONGLONG_MAX.
  This is also a check that ULL type specifier
  can be used on all supported platforms.
mysql-test/r/func_group.result:
  bug #1790, post-review work: test results fixed
sql/item_sum.cc:
  small cleanup
sql/item_sum.h:
  few style fixes.
  BIT_AND and BIT_OR now are both BIGINT UNSIGNED

instead of Log_event::Log_event(THD*, ...) when the event is built in the master
to be written in the binlog.
Rand_log_event already used the good constructor, so there really is no reason
for Intvar_log_event to be an exception.
This fixes a test failure of last night (which appeared after I removed a useless
e.server_id=thd->server_id in log.cc; in fact this line was not useless because
it hid the bad constructor).
Replication tests pass, with Valgrind too.


sql/log_event.h:
  There is no reason that Intvar_log_event's constructor calls Log_event::Log_event()
  instead of Log_event::Log_event(THD*, ...) when the event is built in the master
  to be written in the binlog.
  Rand_log_event already used the good constructor, so there really is no reason
  for Intvar_log_event to be an exception.
  This fixes a test failure of last night (which appeared after I removed a useless
  e.server_id=thd->server_id in log.cc; in fact this line was not useless because
  it hid the bad constructor).

into mysql.com:/home/kostja/mysql/mysql-4.0-1790

into mysql.com:/home/mysql_src/mysql-4.0

which does e.server_id=thd.server_id.


sql/log.cc:
  unneeded: the Intvar_log_event constructor calls the Log_event constructor
  which does e.server_id=thd.server_id.

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

It happens that mysql->client_next->client_next=mysql
and mysql_close() goes into infinite loop.
Results vary from simple sigsegv (FreeBSD), to hard system lockup (Linux)
:)

into mysql.com:/my/mysql-4.0