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

In tables_ok(), when there is no table having "updating==TRUE" in the list,
    return that we don't replicate this statement (the slave is supposed to
    replicate *changes* only).
    In practice, the case can only happen for this statement:
    DELETE t FROM t,u WHERE ... ;
    tables_ok(t,u) will now return 0, which (check all_tables_not_ok())
    will give a chance to tables_ok(t) to run.

were never defined.  This potentially caused problems when trying to link
libmysqld with shared libraries.

  Use only noninlined InnoDB functions in ha_innodb.cc

into gw.mysql.r18.ru:/usr/home/ram/work/4.0.b3376

- Changed reading of config file so that one can use a separate config
  file for [mysqld_multi] also. In other words --config-file=file will
  read group [mysqld_multi] from this file, earlier it wouldn't have.

as we transform the 3.23 Load_log_event into a 4.0 Create_file_log_event which is one
byte longer, we need to increment event_len. The bug was that we did not increment it,
so later in code the end 0 was not seen so there was for example a segfault in
strlen(fname) because fname was not 0-terminated.
Other problems remain in 3.23->4.0 replication of LOAD DATA INFILE but they are less serious:
Exec_master_log_pos and Relay_log_space are incorrect. I'll document them.
They are not fixable without significant code changes (if you fix those problems in 4.0,
you get assertion failures somewhere else etc), * which are already done in 5.0.0 *.

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

  Fix a glitch reported by Philippe Lewicki on the general mailing list: do not print a warning to the .err log if read_key fails with a lock wait timeout error 146

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

if you are printing LOAD DATA INFILE and its USE as comments, don't update 'last_db' (because you
have not actually changed the db in the server).

Backport of a part of this changeset of 4.1:
ChangeSet@1.1753.1.1, 2004-04-05 13:56:05+03:00, monty@mysql.com
which fixes the bug.

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

too big by 6 bytes. So I add code to substract 6 bytes if the master is 3.23.
This is not perfect (because it won't work if the slave I/O thread has not
noticed yet that the master is 3.23), but as long as the slave I/O thread
starts Exec_master_log_pos will be ok.
It must be merged to 4.1 but not to 5.0 (or it can be, because of #if MYSQL_VERSION_ID),
because 5.0 already works if the master is 3.23 (and in a more natural way:
in 5.0 we store the end_log_pos in the binlog and relay log).
I had to move functions from slave.h to slave.cc to satisfy gcc.

instead of stdout or fixed-size memory buffers

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

into eagle.mysql.r18.ru:/home/vva/work/BUG_3361/mysql-4.0

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

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

when dropping database (Bug #3058)

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

into eagle.mysql.r18.ru:/home/vva/work/BUG_3200/mysql-4.0

into eagle.mysql.r18.ru:/home/vva/work/BUG_3200/mysql-4.0

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

  Add an accessor function to set srv_io_thread_op_info, change the type to const char*, also change the type of srv_io_thread_function to const char*

  Add assertions to check that we do not go out of bounds of io thread status array
os0file.c:
  Fix memory corruption (assertion failure on line 244 of sync0sync.c) reported by Miguel in a Windows build of MySQL-4.1.2. The bug is present in all InnoDB versions in Windows, but it depends on how the linker places a static array in srv0srv.c, whether the bug shows itself. 4 bytes were overwritten with a pointer to a statically allocated string: 'get windows aio return value'.

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

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