into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

Changed "SHOW ENGINE ... STATUS" and "SHOW ENGINE ... MUTEX"
to require the PROCESS privilege, instead of SUPER.

Fixed by Damien Katz

transfered by CREATE TABLE/SELECT to the new table.

Re-enable the test case for Bug 30331.

Bug 34311: main.lock_multi.test fails.

Fixed interference between tests: Users were added but not properly removed.
This caused later tests to fail.

into  adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime

into  adventure.(none):/home/thek/Development/cpp/bug33201/my51-bug33201

When issuing a column level grant on a table which require pre-locking the 
server crashed.

The reason behind the crash was that data structures used by the lock api
wasn't properly reinitialized in the case of a column level grant.

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

pre-locking.

The crash was caused by an implicit assumption in check_table_access() that
table_list parameter is always a part of lex->query_tables.

When iterating over the passed list of tables, check_table_access() used
to stop only when lex->query_tables_last_not_own was reached. 
In case of pre-locking, lex->query_tables_last_own is not NULL and points
to some element of lex->query_tables. When the parameter
of check_table_access() was not part of lex->query_tables, loop invariant
could never be violated and a crash would happen when the current table
pointer would point beyond the end of the provided list.

The fix is to change the signature of check_table_access() to also accept
a numeric limit of loop iterations, similarly to check_grant(), and 
supply this limit in all places when we want to check access of tables
that are outside lex->query_tables, or just want to check access to one table.

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

The problem is that the Table_locks_waited was incremented only
when the lock request succeed. If a thread waiting for the lock
gets killed or the lock request is aborted, the variable would
not be incremented, leading to inaccurate values in the variable.

The solution is to increment the Table_locks_waited whenever the
lock request is queued. This reflects better the intended behavior
of the variable -- show how many times a lock was waited.

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/51

and so that it works correctly on Windows.

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/51

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/51

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/51

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged-5.0-rt

into  quad.:/mnt/raid/alik/MySQL/devel/5.0-rt-merged-5.0

into  kaamos.(none):/data/src/opt/mysql-5.1-opt

into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-33618

into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-33618

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/51

Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted)

The server used to crash when REPEAT or another control instruction
was used in conjunction with labels and a LEAVE instruction.

The crash was caused by a missing "pop" of handlers or cursors in the
code representing the stored program. When executing the code in a loop,
this missing "pop" would result in a stack overflow, corrupting memory.

Code generation has been fixed to produce the missing h_pop/c_pop
instructions.

Also, the logic checking that labels at the beginning and the end of a
statement are matched was incorrect, causing Bug 33983.
End labels, when used, must match the label used at the beginning of a block.

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-maint