On crashes generate a user-friendly resolved and demangled stack
trace when libc provides the necessary functions (newer libc on i386,
x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric
stack trace as before, relying on resolve_stack_dump utility.

into  dipika.(none):/opt/local/work/mysql-5.1-runtime

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

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime

into  pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-runtime

The problem is that one can not create a stored routine if sql_mode
contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when
a event is created, the mode is silently lost if sql_mode contains one
of the aforementioned.  This was happening because the table definitions
which stored sql_mode values weren't being updated to accept new values
of sql_mode.

The solution is to update, in a backwards compatible manner, the various
table definitions (columns) that store the sql_mode value to take into
account the new possible values. One incompatible change is that if a event
that is being created can't be stored to the mysql.event table, an error
will be raised.

The tests case also ensure that new SQL modes will be added to the mysql.proc
and mysql.event tables, otherwise the tests will fail.

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

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.

The problem is that deprecated syntax warnings were not being
suppressed when the stored routine is being parsed for the first
execution. It's doesn't make sense to print out deprecated
syntax warnings when the routine is being executed because this
kind of warning only matters when the routine is being created.

The solution is to suppress deprecated syntax warnings when
parsing the stored routine for loading into the cache (might
mean that the routine is being executed for the first time).

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