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

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

To be restored when PB is patched to ignore 
requested safemalloc memory dumps.

Fix a race

Wait at the end of the test for all events to finish.
Then continue to the next result. This should be done, as the
server won't be restarted, and although events are dropped with
drop database, they could still be executing in memory.

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

fix in PB.

- A race condition caused brief unavailablility when trying to acccess
  a table. 
- The variable 'grant_option' was removed to resolve the race condition and
  to simplify the design pattern. This flag was originally intended to optimize
  grant checks.

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

- A race condition caused brief unavailablility when trying to acccess
  a table.
- The unprotected variable 'grant_option' wasn't intended to alternate
  during normal execution. Variable initialization moved to grant_init
  a lines responsible for the alternation are removed. 

into  vajra.(none):/opt/local/work/mysql-5.1-4968-clean

Bug#4968 ""Stored procedure crash if cursor opened on altered table"
Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
stored procedure."
Bug#19733 "Repeated alter, or repeated create/drop, fails"
Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
Bug#24879 "Prepared Statements: CREATE TABLE (UTF8 KEY) produces a 
growing key length" (this bug is not fixed in 5.0)

Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
statements in stored routines or as prepared statements caused
incorrect results (and crashes in versions prior to 5.0.25).

In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
  
The problem of bugs 4968, 19733, 19282 and 6895 was that functions
mysql_prepare_table, mysql_create_table and mysql_alter_table are not
re-execution friendly: during their operation they modify contents
of LEX (members create_info, alter_info, key_list, create_list),
thus making the LEX unusable for the next execution.
In particular, these functions removed processed columns and keys from
create_list, key_list and drop_list. Search the code in sql_table.cc 
for drop_it.remove() and similar patterns to find evidence.
  
The fix is to supply to these functions a usable copy of each of the
above structures at every re-execution of an SQL statement. 
  
To simplify memory management, LEX::key_list and LEX::create_list
were added to LEX::alter_info, a fresh copy of which is created for
every execution.
  
The problem of crashing bug 22060 stemmed from the fact that the above 
metnioned functions were not only modifying HA_CREATE_INFO structure 
in LEX, but also were changing it to point to areas in volatile memory
of the execution memory root.
   
The patch solves this problem by creating and using an on-stack
copy of HA_CREATE_INFO in mysql_execute_command.

Additionally, this patch splits the part of mysql_alter_table
that analizes and rewrites information from the parser into
a separate function - mysql_prepare_alter_table, in analogy with
mysql_prepare_table, which is renamed to mysql_prepare_create_table.

bug#26338 events_bugs.test fail on Debian
and
bug#28285 Test "events_bugs" has instable results of "select /*1*/ ... from processlist"

into  whirlpool.mysql.com:/work/mysql-5.1-runtime

A missing check for zero value of interval was added.

into  four.local.lan:/WORK/mysql-5.1-runtime/src-1

This changeset belongs to the fix of Bug#735 Prepared Statements: there is no support for Query Cache
  
- Create "--ps-protocol" and no "--<whatever>-protocol" variants of the former tests
  t/grant_cache.test and t/query_cache_sql_prepare.test.
- Some additional subtest and fixes of bugs
- Minor improvements 

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

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

into  vajra.(none):/opt/local/work/mysql-5.0-runtime

into  trift2.:/MySQL/M51/push-5.1

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

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

into  adventure.(none):/home/thek/Development/cpp/bug28644/my50-bug28644

This patch removes a false memory leak error report from the test suite.
There is a test case that puposely provokes a SAFEMALLOC leak report,
even though there is no actual leak.

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work

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

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

  Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
              by other connections"
  Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
As well as:
  Bug #25578 "CREATE TABLE LIKE does not require any privileges
              on source table".

The first and the second bugs resulted in various errors and wrong
binary log order when one tried to execute concurrently CREATE TABLE LIKE
statement and DDL statements on source table or DML/DDL statements on its
target table.

The problem was caused by incomplete protection/table-locking against
concurrent statements implemented in mysql_create_like_table() routine.
We solve it by simply implementing such protection in proper way.
Most of actual work for 5.1 was already done by fix for bug 20662 and
preliminary patch changing locking in ALTER TABLE.

The third bug allowed user who didn't have any privileges on table create
its copy and therefore circumvent privilege check for SHOW CREATE TABLE.

This patch solves this problem by adding privilege check, which was missing.

Finally it also removes some duplicated code from mysql_create_like_table()
and thus fixes bug #26869 "TABLE_LIST::table_name_length inconsistent with
TABLE_LIST::table_name".

 Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
             by other connections"
 Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
As well as:
 Bug #25578 "CREATE TABLE LIKE does not require any privileges
             on source table".

The first and the second bugs resulted in various errors and wrong
binary log order when one tried to execute concurrently CREATE TABLE LIKE
statement and DDL statements on source table or DML/DDL statements on its
target table.

The problem was caused by incomplete protection/table-locking against
concurrent statements implemented in mysql_create_like_table() routine.
We solve it by simply implementing such protection in proper way (see
comment for sql_table.cc for details).

The third bug allowed user who didn't have any privileges on table create
its copy and therefore circumvent privilege check for SHOW CREATE TABLE.

This patch solves this problem by adding privilege check, which was missing.

Finally it also removes some duplicated code from mysql_create_like_table().

Note that, altough tests covering concurrency-related aspects of CREATE TABLE
LIKE behaviour will only be introduced in 5.1, they were run manually for
this patch as well.

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