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

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-fix-race

duration of the whole 'flush instances'. As a consequence,
it was possible to query instance map, while it is in the
inconsistent state. The patch was reworked after review.

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-add-error-message

connections correctly".
Recommit with the max timeout value in sync with the comment.

into mysql.com:/home/hf/work/mysql-5.0.w2645

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

fails with --vardir option.

into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0

Fix for BUG#13897 "failure to do SET SQL_MODE=N where N is a number > 31" (the original bug's title isn't the simplest
symptom). sys_var::check_set() was wrong. mysqlbinlog makes use of such SET SQL_MODE=N
(where N is interpreted like if SQL_MODE was a field of type SET), so
this bug affected recovery from binlogs if the server was running with certain SQL_MODE values,
for example the default values on Windows (STRICT_TRANS_TABLES); to work around this bug people
had to edit mysqlbinlog's output.

if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch. 
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.

Fix for BUG#16559 "Replication Problems with Non transactional tables inside an interrupted trans.":
problem was: when a connection disconnects having an open transaction affecting MyISAM and InnoDB, the ROLLBACK event stored in the binary log
contained a non-zero error code (1053 because of the disconnection), so when slave applied the transaction, slave complained that its ROLLBACK succeeded
(error_code=0) while master's had 1053, so slave stopped. But internally generated binlog events such as this ROLLBACK
should always have 0 as error code, as is true in 4.1 and was accidentally broken in 5.0,
so that there is no false alarm.

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-add-error-message

into  mysql.com:/home/jimw/my/mysql-5.0-clean

into  snake-hub.snake.net:/src/extern/MySQL/bk/mysql-5.0

  Tweak --check-upgrade help text.

into moonbone.local:/work/15706-bug-5.0-mysql

into mysql.com:/home/hf/work/mysql-5.0.w2645

necessary implementation in the server
mysql_upgrade script added

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

  Fix out of order options.

into  mysql.com:/home/dlenev/src/mysql-5.0-bg16593

trigger starts trigger".

In short, the deadlock/crash happened when execution of statement, which used
stored functions or activated triggers, coincided with alteration of the
tables used by these functions or triggers (in highly concurrent environment).

Bug was caused by the incorrect handling of tables from prelocked set in
open_tables() functions in situations when refresh happened. This fix replaces
old smart but not very robust way of handling tables after refresh (which was
closing only old tables), with new one which simply closes all tables opened so
far and restarts open_tables().
Also fixed handling of temporary tables in close_tables_for_reopen().

No test case present since bug manifests itself only in concurrent environment.

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

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

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

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

into  mysql.com:/home/stewart/Documents/MySQL/5.0/bug17411-thisisaverylongnamethatshouldbewaylongerthanthe128limitthatweprivouslyhadbutireallywantotestitandseethatitdoesreallywork.nowitshouldbeabout160charslongnonow.iwonderifanythingwillchokeornotwiththisoutrageouslylongpathname

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  mysql.com:/home/jimw/my/mysql-5.0-clean

into  mysql.com:/home/jimw/my/mysql-5.0-clean

If item->cached_table is set, find_field_in_tables() returns found field
even if it doesn't belong to current select. Because Item_field::fix_fields
doesn't expect such behaviour, reported bug occurs.

Item_field::fix_fields() was modifed to detect when find_field_in_tables() 
can return field from outer select and process such fields accordingly.
In order to ease this code which was searching and processing outed fields was
moved into separate function called Item_field::fix_outer_field().

A follow-up to BUG#15011 (already fixed).