into  chilla.local:/home/mydev/mysql-5.0

into  dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge

into  gbichot3.local:/home/mysql_src/mysql-5.0

into  dsl-hkigw8-feb1fb00-100.dhcp.inet.fi:/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/5.0/20919_temp_nlog

closing temp tables through end_thread
had a flaw in binlog-off branch of close_temporary_tables where
next table to close was reset via table->next
 for (table= thd->temporary_tables; table; table= table->next)
which was wrong since the current table instance got destoyed at
	close_temporary(table, 1);

The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.

into  gbichot3.local:/home/mysql_src/mysql-5.0

into  gbichot3.local:/home/mysql_src/mysql-5.0

a too large value": the bug was that if MySQL generated a value for an
auto_increment column, based on auto_increment_* variables, and this value
was bigger than the column's max possible value, then that max possible
value was inserted (after issuing a warning). But this didn't honour
auto_increment_* variables (and so could cause conflicts in a master-master
replication where one master is supposed to generated only even numbers,
and the other only odd numbers), so now we "round down" this max possible
value to honour auto_increment_* variables, before inserting it.

auto_increment breaks binlog":
if slave's table had a higher auto_increment counter than master's (even
though all rows of the two tables were identical), then in some cases,
REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
statement-based (it inserted different values on slave from on master).
write_record() contained a "thd->next_insert_id=0" to force an adjustment
of thd->next_insert_id after the update or replacement. But it is this
assigment introduced indeterminism of the statement on the slave, thus
the bug. For ON DUPLICATE, we replace that assignment by a call to
handler::adjust_next_insert_id_after_explicit_value() which is deterministic
(does not depend on slave table's autoinc counter). For REPLACE, this
assignment can simply be removed (as REPLACE can't insert a number larger
than thd->next_insert_id).
We also move a too early restore_auto_increment() down to when we really know
that we can restore the value.

into  mysql.com:/home/mydev/mysql-5.0-ateam

into  mysql.com:/home/mydev/mysql-5.0-ateam

into  mysql.com:/home/mydev/mysql-5.0-ateam

into  mysql.com:/home/mydev/mysql-5.0-ateam

into  mysql.com:/home/mydev/mysql-4.1-bug14400

into  mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl

 Disabling 'rpl_openssl'.

 Enabling rpl_openssl.test for Windows to check that
 currently it still hangs (because I can't reproduce
 this on my machine).

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

+ adopted signal to be as close as possible to 5.1...

It was possible that fetching a record by an exact key value 
(including the record pointer) could return a record with a 
different key value. This happened only if a concurrent insert 
added a record with the searched key value after the fetching 
statement locked the table for read.

The search succeded on the key value, but the record was
rejected as it was past the file length that was remembered
at start of the fetching statement. With other words it was 
rejected as being a concurrently inserted record.

The action to recover from this problem was to fetch the 
record that is pointed at by the next key of the index. 
This was repeated until a record below the file length was 
found.

I do now avoid this loop if an exact match was searched. 
If this match is beyond the file length, it is now treated 
as "key not found". There cannot be another key with the 
same record pointer.

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

A corrupt table with dynamic record format can crash the 
server when trying to select from it.
        
I fixed the crash that resulted from the particular type 
of corruption that has been reported for this bug.

No test case. To test it, one needs a table with a very special
corruption. The bug report contains a file with such a table.

In the Windows build files, the "Max nt" configuration for some reason
had the mysql_client_test project disabled. Enable it.

CHECK TABLE could complain about a fully intact spatial index.
A wrong comparison operator was used for table checking. 
The result was that it checked for non-matching spatial keys. 
This succeeded if at least two different keys were present, 
but failed if only the matching key was present.

I fixed the key comparison.

Improved definition of mysys configuration for -nt builds.

Make sure for the mysys project that __NT__ is defined in *nt solution
configurations (but not in other configurations).

into  mysql.com:/home/alexi/bugs/mysql-5.0-19208

 and BUG#19208 "Test 'rpl000017' hangs on Windows".
 Both bugs are caused by attempting to delete an opened
 file and to create immediatedly a new one with the same
 name. On Windows it can be supported only on NT-platforms
 (by using FILE_SHARE_DELETE mode and with renaming the
 file before deletion). Because deleting not-closed files
 is not supported on all platforms (e.g. Win 98|ME) this
 is to be considered harmful and should be eliminated by
 a "code redesign".

Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.

Ignoring of these options is documented in the symbolic links
section of the manual.

Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)

into mysql.com:/home/hf/work/mysql-4.1.clean

Very complex select statements can create temporary tables
that are too big to be represented as a MyISAM table.

This was not checked at table creation time, but only at
open time. The result was an attempt to delete the 
"impossible" table.

But if the server is built --with-raid, MyISAM tries to 
open the table before deleting the files. It needs to find 
out if the table uses the raid support and how many raid 
chunks there are. This is done with an open "for repair",
which will almost always succeed.

But in this case we have an "impossible" table. The open
failed. Hence the files were not deleted. Also the error
message was a bit unspecific.

I turned an open error in this situation into the assumption 
of having no raid support on the table. Thus the normal data 
file is tried to be deleted. This may however leave existing 
raid chunks behind.

I also added a check in mi_create() to prevent the creation
of an "impossible" table. A more decriptive error message is
given in this case.

No test case. The required select statement is way too
large for the test suite. I added a test script to the
bug report.