After merge fix

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


myisam/mi_dynrec.c:
  Auto merged

After merge fix

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


myisam/mi_dynrec.c:
  Auto merged

into  chilla.local:/home/mydev/mysql-4.1-bug20719


myisam/mi_dynrec.c:
  Bug#20719 - Reading dynamic records with write buffer could fail
  Manual merge

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

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

Fixed a possible problem with reading of dynamic records
when a write cache is active. The cache must be flushed
whenever a part of the file in the write cache is to be 
read.

Added a read optimization to _mi_read_dynamic_record().

No test case. This was a hypothetical but existing problem.


myisam/mi_dynrec.c:
  Bug#20719 - Reading dynamic records with write buffer could fail
  
  Fixed a possible problem with reading of dynamic records
  when a write cache is active. The cache must be flushed
  whenever a part of the file in the write cache is to be 
  read. This must be done before the read of the header
  and before the read of the rest block.
  
  Renamed the 'flag' and 'skipp_deleted_blocks' variables.
  
  Added a read optimization to _mi_read_dynamic_record()
  that was present in _mi_read_rnd_dynamic_record() already.
  After _mi_get_block_info() we have some bytes of the record
  in the header buffer already. No need to read them again.

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.