Fix random failures in test 'wait_timeout' that depend on exact timing.

1. Force a reconnect initially if necessary, as otherwise slow startup
might have caused a connection timeout before the test can even start.

2. Explicitly disconnect the first connection to remove confusion about
which connection aborts from timeout, causing test failure.


mysql-test/r/wait_timeout.result:
  Fix two races in test.
mysql-test/t/wait_timeout.test:
  Fix two races in test.

into  mysql.com:/nfstmp1/ingo/autopush-75/mysql-5.0

into  mysql.com:/home/alik/MySQL/devel/5.0-rt

into  mysql.com:/home/mydev/mysql-5.0-bug16986-main


sql/sql_table.cc:
  Auto merged

into  mysql.com:/home/mydev/mysql-5.0-bug16986-main


sql/mysql_priv.h:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/sql_parse.cc:
  Auto merged

Addendum fixes after changing the condition variable
for the global read lock.

The stress test suite revealed some deadlocks. Some were
related to the new condition variable (COND_global_read_lock)
and some were general problems with the global read lock.

It is now necessary to signal COND_global_read_lock whenever 
COND_refresh is signalled.

We need to wait for the release of a global read lock if one 
is set before every operation that requires a write lock.
But we must not wait if we have locked tables by LOCK TABLES.
After setting a global read lock a thread waits until all
write locks are released.


mysql-test/r/lock_multi.result:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Added test results.
mysql-test/t/lock_multi.test:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Added tests for possible deadlocks that did not occur
  with the stress test suite.
mysys/thr_lock.c:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Added a protection against an infinite loop that occurs
  with the test case for Bug #20662.
sql/lock.cc:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Signal COND_global_read_lock whenever COND_refresh
  is signalled by using the new function broadcast_refresh().
  Added the definition of a new function that signals 
  COND_global_read_lock whenever COND_refresh is signalled.
sql/mysql_priv.h:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Added a declaration for a new function that signals 
  COND_global_read_lock whenever COND_refresh is signalled.
sql/sql_base.cc:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Signal COND_global_read_lock whenever COND_refresh
  is signalled by using the new function broadcast_refresh().
sql/sql_handler.cc:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Signal COND_global_read_lock whenever COND_refresh
  is signalled by using the new function broadcast_refresh().
sql/sql_insert.cc:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Removed global read lock handling from inside of 
  INSERT DELAYED. It is handled on a higher level now.
sql/sql_parse.cc:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Wait for the release of a global read lock if one is set
  before every operation that requires a write lock.
  But don't wait if locked tables exist already.
sql/sql_table.cc:
  Bug#16986 - Deadlock condition with MyISAM tables
  Addendum fixes after changing the condition variable
  for the global read lock.
  Removed global read lock handling from inside of 
  CREATE TABLE. It is handled on a higher level now.
  Signal COND_global_read_lock whenever COND_refresh
  is signalled by using the new function broadcast_refresh().

into  mysql.com:/home/tnurnberg/mysql-5.0-maint-18462


mysql-test/r/mysqldump.result:
  Auto merged
mysql-test/t/mysqldump.test:
  Auto merged
client/mysqldump.c:
  SCCS merged

into  mysql.com:/data0/bk/mysql-5.0-maint


sql/sp_head.cc:
  Auto merged
sql/table.cc:
  Auto merged

into  mysql.com:/data0/knielsen/tmp-5.0

Sometimes the helper connection (that is watching for the main connection
to time out) would itself time out first, causing the test to fail.


mysql-test/t/wait_timeout.test:
  Increase connection timeout in connection wait_con so we will not loose
  the connection that is watching for the real wait_timeout to trigger.

into  mysql.com:/mnt/storeage/mysql-5.0-maint_bug20616

sql/sql_table.cc:
  Check for FN_DEVCHAR in the table name just before file creation. This allows for temporary tables to contain FN_DEVCHAR in the name.
sql/table.cc:
  Removed the check for FN_DEVCHAR is done at this level because it prevents Windows from creating any table with FN_DEVCHAR in the name.

  After merge fix


mysql-test/r/key.result:
  After merge fix

into  mysql.com:/usr/local/mysql/tmp-5.0

The problem was a call to convert_dirname() with a destination buffer
that did not have room for the trailing slash added by that function.
This could cause the instance manager to crash in some cases.


mysys/mf_dirname.c:
  Clarify in comments that convert_dirname destination must be larger than
  source to accomodate a trailing slash.
server-tools/instance-manager/instance_options.cc:
  Fix buffer overrun.

into moonbone.local:/work/tmp_merge-5.0-opt-mysql


sql/sql_parse.cc:
  Auto merged

into moonbone.local:/work/tmp_merge-5.0-opt-mysql


mysql-test/r/key.result:
  Auto merged
mysql-test/t/key.test:
  Auto merged
sql/table.cc:
  Auto merged
support-files/mysql.spec.sh:
  Auto merged

  An UNIQUE KEY consisting of NOT NULL columns
  was displayed as PRIMARY KEY in "DESC t1".
  According to the code, that was intentional
  behaviour for some reasons unknown to me.
  This code was written before bitkeeper time,
  so I cannot check who and why made this.
  After discussing on dev-public, a decision
  was made to remove this code


mysql-test/r/key.result:
  Adding test case.
mysql-test/t/key.test:
  Adding test case.
sql/table.cc:
  Removing old wrong code

  Disable the simplistic auto dependency scan for test/bench (bug#20078)


support-files/mysql.spec.sh:
  Disable the simplistic auto dependency scan for test/bench (bug#20078)

into  mysql.com:/home/tnurnberg/mysql-5.0-maint-19409

into  mysql.com:/opt/local/work/mysql-5.0-runtime

into  clam.ndb.mysql.com:/space/pekka/ndb/version/my50-bug18781


ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
  Auto merged
ndb/src/ndbapi/ndberror.c:
  Auto merged

- The setting of "ENV{'TZ'}" doesn't affect the timezone
  used by MySQL Server on Windows.
- Explicitly set timezone in test cases before doing UTC/localtime
  conversions so tests produce deterministic results


mysql-test/r/func_timestamp.result:
  Update test results
mysql-test/r/type_timestamp.result:
  Update test results
mysql-test/t/func_timestamp.test:
  Specifically set timezone to make tests that do localtime/UTC conversions deterministic
mysql-test/t/type_timestamp.test:
  Specifically set timezone to make tests that do localtime/UTC conversions deterministic

- The setting of "ENV{'TZ'}" doesn't affect the timezone
  used by MySQL Server on Windows.
- Explicitly set timezone to "+03:00" in test case before
  doing the calculatiosn to check that there is three hours
  difference between utc and local time.
(Magnus' fix)


mysql-test/r/func_time.result:
  Update test results
mysql-test/t/func_time.test:
  Set timezone to GMT-3, to make it possible to use "interval 3 hour"

into  mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug15811

into  mysql.com:/opt/local/work/mysql-5.0-runtime

into  mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug15811

 with PREPARE fails with weird error".
More generally, re-executing a stored procedure with a complex SP cursor query
could lead to a crash.

The cause of the problem was that SP cursor queries were not optimized 
properly at first execution: their parse tree belongs to sp_instr_cpush,
not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
cursor was declared, not when it was opened. This led to loss of optimization
transformations performed at first execution, as sp_instr_copen saw that the
query is already "EXECUTED" and therefore either not ran first-execution 
related blocks or wrongly rolled back the transformations caused by 
first-execution code.
The fix is to update the state of the parsed tree only when the tree is
executed, as opposed to when the instruction containing the tree is executed.
Assignment if i->state is moved to reset_lex_and_exec_core.


mysql-test/r/sp.result:
  Test results fixed (Bug#15217)
mysql-test/t/sp.test:
  Add a test case for Bug#15217
sql/sp_head.cc:
  Move assignment of stmt_arena->state to reset_lex_and_exec_core

The problem was in redundant calls to strlen() in string functions,
where we may then return after checking only the small number of characters.

No test case is provided since it's a performance fix.


strings/ctype-mb.c:
  Do not use strlen() where arbitrary horizon of at least
  CHARSET_INFO::mbmaxlen character is sufficient.

into moonbone.local:/work/tmp_merge-5.0-opt-mysql

into  zippy.(none):/home/cmiller/work/mysql/mysql-5.0__bug19904

into moonbone.local:/work/tmp_merge-5.0-opt-mysql

into  a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0

mysql-test/r/ctype_utf8.result:
  Auto merged
mysql-test/t/ctype_utf8.test:
  Auto merged

into moonbone.local:/work/tmp_merge-5.0-opt-mysql

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

This bug in Field_string::cmp resulted in a wrong comparison 
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
  
Wrong key comparisons could lead to wrong result sets if 
the selected query execution plan used a range scan by 
a partial index over a utf8 character field.
This also caused wrong results in many other cases.


mysql-test/t/ctype_utf8.test:
  Added test cases for bug #14896.
mysql-test/r/ctype_utf8.result:
  Added test cases for bug #14896.
sql/field.cc:
  Fixed bug #14896.
  This bug in Field_string::cmp resulted in a wrong comparison 
  with keys in partial indexes over multi-byte character fields.
  Given field a is declared as a varchar(16) collate utf8_unicode_ci
  INDEX(a(4)) gives us an example of such an index.
       
  Wrong key comparisons could lead to wrong result sets if 
  the selected query execution plan used a range scan by 
  a partial index over a utf8 character field.
  This also caused wrong results in many other cases.

into  mysql.com:/home/bk/fix-mysql-5.0

into  a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0