into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25044

tables' lock."

Execution of ALTER TABLE ... ENABLE KEYS on a table (which can take rather
long time) prevented concurrent execution of all statements using tables.

The problem was caused by the fact that we were holding LOCK_open mutex
during whole duration of this statement and particularly during call
to handler::enable_indexes(). This behavior was introduced as part of the
fix for bug 14262 "SP: DROP PROCEDURE|VIEW (maybe more) write to binlog
too late (race cond)"

The patch simply restores old behavior. Note that we can safely do this as
this operation takes exclusive lock (similar to name-lock) which blocks both
DML and DDL on the table being altered.

It also introduces mysql-test/include/wait_show_pattern.inc helper script
which is used to make test-case for this bug robust enough.

into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.1-bug25211

The problem was that the events_bugs test could randomly fail due to
races in the test case.

The solution is to replace fixed sleeps with reliable polling of a
certain state to settle.  For that, a new auxiliary script
include/wait_condition.inc is used, that allows waiting for a given
query to return true.

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-24562-merge

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-24562-merge

WL#3681 (ALTER TABLE ORDER BY)

Before this fix, the ALTER TABLE statement implemented an ORDER BY option
with the following characteristics :

1) The order by clause accepts a list of criteria, with optional ASC or
DESC keywords

2) Each criteria can be a general expression, involving operators,
native functions, stored functions, user defined functions, subselects ...

With this fix :

1) has been left unchanged, since it's a de-facto existing feature,
that was already present in the code base and partially covered in the test
suite. Code coverage for ASC and DESC was missing and has been improved.

2) has been changed to limit the kind of criteria that are permissible:
now only a column name is valid.

into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.1-bug24404

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

into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.1-bug24404

The problem was that if a prepared statement accessed a view, the
access to the tables listed in the query after that view was done in
the security context of the view.

The bug was in the assigning of the security context to the tables
belonging to a view: we traversed the list of all query tables
instead.  It didn't show up in the normal (non-prepared) statements
because of the different order of the steps of checking privileges
and descending into a view for normal and prepared statements.

The solution is to traverse the list and stop once the last table
belonging to the view was processed.

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-debug-max

by the patch for Bug#4968

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

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

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

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

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg20390

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-6298

into  bodhi.local:/opt/local/work/mysql-5.1-root

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

into  bodhi.local:/opt/local/work/mysql-5.1-runtime

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

into  trift2.:/MySQL/M50/push-5.0

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg20390

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

into  bodhi.local:/opt/local/work/mysql-5.0-4968-to-push