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

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

into  mysql.com:/home/stewart/Documents/MySQL/5.0/main

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

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-release

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

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

+ adopted signal to be as close as possible to 5.1...

  Fix compile error for forte

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

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

It was hard to distinguish case, when one was unable to create trigger
on the table because trigger with same action time and event already
existed for this table, from the case, when one tried to create trigger
with name which was already occupied by some other trigger, since in
both these cases we emitted ER_TRG_ALREADY_EXISTS error and message.
Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional
message in the first case. There is no sense in introducing separate
error for this situation since we plan to get rid of this limitation
eventually.

No test case as the bug is in an existing test case (rpl_trigger.test
when it is run under valgrind).
The warning was caused by memory corruption in replication slave: thd->db
was pointing at a stack address that was previously used by 
sp_head::execute()::old_db. This happened because mysql_change_db
behaved differently in replication slave and did not make a copy of the 
argument to assign to thd->db. 
The solution is to always free the old value of thd->db and allocate a new
copy, regardless whether we're running in a replication slave or not.

Pushbuild fixes to result file, test, and header file for federated.

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

into  govinda.patg.net:/home/patg/mysql-build/mysql-5.0-engines-bug19773

into  xiphis.org:/home/antony/work2/p4-bug12096.2-merge

into  mysql.com:/home/stewart/Documents/MySQL/5.0/merge

into  mysql.com:/home/stewart/Documents/MySQL/5.0/merge

change default minimum to 3

bug is *very* timing dependent, unable to reproduce here, but theoretically possible.

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

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

  
sp_grant_privileges(), the function that GRANTs EXECUTE + ALTER privs on a SP,
did so creating a user-entry with not password; mysql_routine_grant() would then
write that "change" to the user-table.

into mysql.com:/home/gluh/MySQL/Merge/5.0-kt

  
Final-review fixes per Monty, pre-push. OK'd for 
push. Please see each file's comments.

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

Bug #18361: Triggers on mysql.user table cause server crash

 Because they do not work, we do not allow creating triggers on tables
 within the 'mysql' schema.

 (They may be made to work and re-enabled at some later date, but not
 in 5.0 or 5.1.)

into mysql.com:/M50/autopush20216-5.0

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

This finishes bug#18516, as far as "generic RPMs" are concerned.

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

The problem was that we restored SQL_CACHE, SQL_NO_CACHE flags in SELECT
statement from internal structures based on value set later at runtime, not
the original value set by the user.

The solution is to remember that original value.

manual merge from 4.0.