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.

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.

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

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

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

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

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-5.0

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1

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

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1

            functions in queries

Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
results in error 124 (wrong index) from storage engine.

The problem was that optimizer use disabled index to optimize
MAX()/MIN(). Normally it must skip disabled index and perform
table scan.

This patch skips disabled indexes for min/max optimization.

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

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

Backport Valgrind suppression from mysql-5.1:

D 1.4 05/11/23 22:44:54+02:00 monty@mysql.com 5 4 12/0/154
P mysql-test/valgrind.supp
C Remove warning that may happens becasue threads dies in different order

into  mysql.com:/home/marty/MySQL/mysql-5.0

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

into  mysql.com:/home/marty/MySQL/mysql-5.0

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

into  mysql.com:/usr/home/ram/work/mysql-5.0

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

function crashes server".

Attempts to execute prepared multi-delete statement which involved trigger or
stored function caused server crashes (the same happened for such statements
included in stored procedures in cases when one tried to execute them more
than once).

The problem was caused by yet another incorrect usage of check_table_access()
routine (the latter assumes that table list which it gets as argument
corresponds to value LEX::query_tables_own_last). We solve this problem by
juggling with LEX::query_tables_own_last value when we call
check_table_access() for LEX::auxilliary_table_list (better solution is too
intrusive and should be done in 5.1).

  Additional fix for #16377 for bigendian platforms
sql_select.cc, select.result, select.test:
  After merge fix

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

In addition to include "mysql_upgrade" in a RPM, it should also be called
when the RPM is upgraded.

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

  Added test case for bug#18759 Incorrect string to numeric conversion.  
select.test:
  Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
  Cleanup after fix for bug#18360 removal

Clearing active VIO before calling mysql_close() in the slave I/O
thread. 

into  mysql.com:/home/emurphy/mysql-5.0-heikki

Fixes bug#17264, for alter table on win32 for successfull operation completion
it is used TL_WRITE(=10) lock instead of TL_WRITE_ALLOW_READ(=6), however here
in innodb handler TL_WRTIE is lifted to TL_WRITE_ALLOW_WRITE, which causes
race condition when several clients do alter table simultaneously.

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