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

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


ndb/include/kernel/GlobalSignalNumbers.h:
  Auto merged
ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
  Auto merged
ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
  Auto merged
ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  Auto merged
ndb/src/ndbapi/ndberror.c:
  Auto merged

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

ndb/src/kernel/blocks/dbdict/DictLock.txt:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/blocks/dbdih/Dbdih.hpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/vm/SimulatedBlock.cpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/src/kernel/vm/SimulatedBlock.hpp:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD
ndb/test/run-test/daily-basic-tests.txt:
  wait until SL_STARTED before sending DICT_UNLOCK_ORD

ndb/include/kernel/GlobalSignalNumbers.h:
  5.0 : add NODE_START_REP from 5.1
ndb/src/common/debugger/signaldata/SignalNames.cpp:
  5.0 : add NODE_START_REP from 5.1
ndb/src/kernel/blocks/ndbcntr/NdbcntrMain.cpp:
  5.0 : add NODE_START_REP from 5.1
ndb/src/kernel/vm/SimulatedBlock.cpp:
  5.0 : add NODE_START_REP from 5.1
ndb/src/kernel/vm/SimulatedBlock.hpp:
  5.0 : add NODE_START_REP from 5.1

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


sql/sql_base.cc:
  Manual merge

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.



sql/sql_base.cc:
  no-binlog branch is fixed: scanning across temporary_tables must be careful to save next table since the current is being destroyed inside of close_temporary. 
  binlog-is-open case is ok.

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

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


sql/handler.cc:
  Auto merged
sql/handler.h:
  Auto merged
sql/sql_insert.cc:
  Auto merged

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.


mysql-test/r/rpl_auto_increment.result:
  result update. Before the fix, the result was that master inserted 127 in t1
  (which didn't honour auto_increment_* variables!),
  instead of failing with "duplicate key 125" like now.
mysql-test/t/rpl_auto_increment.test:
  Test for BUG#20524 "auto_increment_* not observed when inserting
  a too large value".
  We also check the pathological case (table t2) where it's impossible to
  "round down".
  The fixer of BUG#20573 will be able to use table t2 for testing his fix.
sql/handler.cc:
  If handler::update_auto_increment() generates a value larger than the field's
  max possible value, we used to simply insert this max possible value
  (after pushing a warning). Now we "round down" this max possible value to
  honour auto_increment_* variables (if at all possible), before trying the
  insertion.

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.


mysql-test/r/rpl_insert_id.result:
  result update, without the bugfix, slave's "3 350" were "4 350".
mysql-test/t/rpl_insert_id.test:
  test for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in
  auto_increment breaks binlog".
  There is, in this order:
  - a test of the bug for the case of REPLACE
  - a test of basic ON DUPLICATE KEY UPDATE functionality which was not
  tested before
  - a test of the bug for the case of ON DUPLICATE KEY UPDATE
sql/handler.cc:
  the adjustment of next_insert_id if inserting a big explicit value, is
  moved to a separate method to be used elsewhere.
sql/handler.h:
  see handler.cc
sql/sql_insert.cc:
  restore_auto_increment() means "I know I won't use this autogenerated
  autoincrement value, you are free to reuse it for next row". But we were
  calling restore_auto_increment() in the case of REPLACE: if write_row() fails
  inserting the row, we don't know that we won't use the value, as we are going to
  try again by doing internally an UPDATE of the existing row, or a DELETE
  of the existing row and then an INSERT. So I move restore_auto_increment()
  further down, when we know for sure we failed all possibilities for the row.
  Additionally, in case of REPLACE, we don't need to reset THD::next_insert_id:
  the value of thd->next_insert_id will be suitable for the next row.
  In case of ON DUPLICATE KEY UPDATE, resetting thd->next_insert_id is also
  wrong (breaks statement-based binlog), but cannot simply be removed, as
  thd->next_insert_id must be adjusted if the explicit value exceeds it.
  We now do the adjustment by calling
  handler::adjust_next_insert_id_after_explicit_value() (which, contrary to
  thd->next_insert_id=0, does not depend on the slave table's autoinc counter,
  and so is deterministic).

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


myisam/mi_dynrec.c:
  Auto merged

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


myisam/mi_key.c:
  Auto merged
mysql-test/r/gis-rtree.result:
  Auto merged
mysql-test/t/gis-rtree.test:
  Auto merged
myisam/mi_check.c:
  SCCS merged

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


libmysqld/libmysqld.c:
  Auto merged
myisam/mi_rkey.c:
  Auto merged
mysql-test/r/func_sapdb.result:
  Auto merged
mysql-test/r/symlink.result:
  Auto merged
mysql-test/t/func_sapdb.test:
  Auto merged
scripts/make_binary_distribution.sh:
  Auto merged
sql/item_geofunc.h:
  Auto merged
sql/item_timefunc.cc:
  Auto merged
sql/sql_class.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged
libmysqld/lib_sql.cc:
  Manual merge
mysql-test/r/func_time.result:
  Manual merge
mysql-test/r/gis.result:
  Manual merge
mysql-test/t/func_time.test:
  Manual merge
mysql-test/t/gis.test:
  Manual merge
sql-common/client.c:
  Manual merge

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


myisam/mi_create.c:
  Auto merged
mysql-test/r/ctype_utf8.result:
  Auto merged
mysql-test/r/key.result:
  Auto merged
mysql-test/r/myisam.result:
  Auto merged
mysql-test/t/ctype_utf8.test:
  Auto merged
mysql-test/t/key.test:
  Auto merged
mysql-test/t/myisam.test:
  Auto merged
sql/opt_sum.cc:
  Auto merged
sql/table.cc:
  Auto merged
support-files/mysql.spec.sh:
  Auto merged
sql/field.cc:
  Manual merge

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


myisam/mi_rkey.c:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Manual merge
sql/sql_class.cc:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Manual merge

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

 Disabling 'rpl_openssl'.


mysql-test/t/rpl_openssl.test:
  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).


mysql-test/t/rpl_openssl.test:
  Enabling rpl_openssl.test for Windows

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


sql/ha_ndbcluster.cc:
  Auto merged

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


sql/ha_ndbcluster.cc:
  manual merge

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


myisam/mi_rkey.c:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Added a check for exact key match before searching for
  the next key that was not concurrently inserted. If an
  exact key match finds a concurrently inserted row, this
  must be treated as "key not found".
sql/sql_class.cc:
  Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
  Fixed some DBUG_ENTER strings.

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


sql/ha_ndbcluster.cc:
  Auto merged

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.


myisam/mi_dynrec.c:
  Bug#19835 - Binary copy of corrupted tables crash the server when issuing a query
  Added a protection against corrupted records. A dynamic 
  record header with invalid 'next' pointer could trigger 
  the assert in _mi_get_block_info(). Now I avoid this by 
  reporting a corruption error.

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


VC++Files/mysql.sln:
  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.


myisam/mi_check.c:
  Bug#17877 - Corrupted spatial index
  Fixed the comparison operator for checking a spatial index.
  Using MBR_EQUAL | MBR_DATA to compare for equality and
  include the data pointer in the comparison. The latter
  finds the index entry that points to the current record.
  This is necessary for non-unique indexes.
  
  The old operator, SEARCH_SAME, is unknown to the rtree
  search functions and handled like MBR_DISJOINT.
myisam/mi_key.c:
  Bug#17877 - Corrupted spatial index
  Added a missing DBUG_RETURN.
myisam/rt_index.c:
  Bug#17877 - Corrupted spatial index
  Included the data pointer in the copy of the search key.
  This is necessary for searching the index entry that points
  to a specific record if the search_flag contains MBR_DATA.
myisam/rt_mbr.c:
  Bug#17877 - Corrupted spatial index
  Extended the RT_CMP() macro with an assert for an 
  unexpected comparison operator.
mysql-test/r/gis-rtree.result:
  Bug#17877 - Corrupted spatial index
  The test result.
mysql-test/t/gis-rtree.test:
  Bug#17877 - Corrupted spatial index
  The test case.

Improved definition of mysys configuration for -nt builds.


VC++Files/mysql.sln:
  Use the name 'nt' instead of 'Release' for configuration.
VC++Files/mysys/mysys.vcproj:
  Use the name 'nt' instead of 'Release' for configuration.
  Use separate output files for NT and non-NT configurations.

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


VC++Files/mysql.sln:
  Define __NT__ in mysys for *nt configurations.
VC++Files/mysys/mysys.vcproj:
  Add configurations with __NT__ defined.
mysql-test/mysql-test-run.pl:
  Also allow testing a "Max nt" build.

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


VC++Files/mysys/mysys.vcproj:
  To be sure that __NT__ is defined for Win configurations.
   Temporary, to be changed in more appropriate way.
include/my_sys.h:
  Adding my_delete_allow_opened to be invoked to delete
   a (possibly) not closed file on Windows NT-platforms.
mysys/my_delete.c:
  Adding nt_share_delete() function implementing
   a (possibly) not closed file deletion on Windows NT.
sql/log.cc:
  MYSQL_LOG::reset_logs(): Deleting usually not
   closed binlog files.

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.


mysql-test/r/symlink.result:
  Modified test result according to fix for BUG#1662.
sql/sql_parse.cc:
  Produce a warning if DATA/INDEX DIRECTORY is specified in
  ALTER TABLE statement.

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


mysql-test/r/func_sapdb.result:
  test cases for date range edge cases added
mysql-test/r/func_time.result:
  test cases for date range edge cases added
mysql-test/t/func_sapdb.test:
  test cases for date range edge cases added
mysql-test/t/func_time.test:
  test cases for date range edge cases added

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.


myisam/mi_create.c:
  Bug#11824 - internal /tmp/*.{MYD,MYI} files remain, causing subsequent queries to fail
  Added a check to mi_create() that the table description
  header of the index file does not exceed 64KB. The header
  has only 16 bits to encode its length.
myisam/mi_delete_table.c:
  Bug#11824 - internal /tmp/*.{MYD,MYI} files remain, causing subsequent queries to fail
  Interpret error in table open as not having a raid
  configuration on the tbale. Thus try to delete the
  normal data file, but leave behind raid chunks if 
  they exist.