The problem was a race condition in a test case.

The fix eliminates the race condition by explicit
wait on UNIX socket to start accepting connections.

The patch affects only test suite (i.e. does not touch
server codebase).

into  booka.:/home/alik/MySQL/devel/5.0-rt

wrong results in order by in some rare cases.

into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0

into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21081

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726

Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.

The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).

The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.

Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.

Version 5.1 does not have this bug (it was fixed by WL 3146).

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines

into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg20670-2

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21081

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

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

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines

Was introduced with patch for bug#21675.

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

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

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines

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

into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge

into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge

  After merge fix

into  moonbone.local:/work/5505-bug-5.0-opt-mysql

On an INSERT into an updatable but non-insertable view an error message was
issued stating the view being not updatable. This can lead to a confusion of a
user.

A new error message is introduced. Is is showed when a user tries to insert
into a non-insertable view.

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

create_tmp_table()".

The fix for bug 21787 "COUNT(*) + ORDER BY + LIMIT returns wrong
result" introduced valgrind warnings which occured during execution
of information_schema.test and sp-prelocking.test in version 5.0.
There were no user visible effects.

The latter fix made create_tmp_table() dependant on
THD::lex::current_select value. Valgrind warnings occured when this
function was executed and THD::lex::current_select member pointed
to uninitialized SELECT_LEX instance.

This fix tries to remove this dependancy by moving some logic
outside of create_tmp_table() function.

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

into  mysql.com:/home/svoj/devel/mysql/BUG21617/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/BUG21617/mysql-4.1-engines

Crash may happen when selecting from a merge table that has underlying
tables with less indexes than in a merge table itself.

If number of keys in merge table is not bigger than requested key number,
return error.

into  mysql.com:/home/svoj/devel/mysql/BUG21675/mysql-5.0-engines

into  mysql.com:/home/svoj/devel/mysql/BUG21675/mysql-5.0-engines

If mysqld is linked against system installed zlib (which is likely compiled w/o
LFS) and archive table exceedes 2G, mysqld will likely be terminated with SIGXFSZ.

Prior to actual write perform a check if there is space in data file. This fixes
abnormal process termination with SIGXFSZ.

No test case for this bugfix.

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