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

  cache by changing the behavior of the query cache resize-method.
- set query_cache_size=<new_size>; is significantly faster than RESET QUERY
  CACHE as it simply destroys and recreates the query cache, whereas
  RESET QUERY CACHE keeps its internal structure aligned with server 
  load profile.

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

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  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.1-engines

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

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  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build-work

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-single-user

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-single-user

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb

into  whalegate.ndb.mysql.com:/home/tomas/mysql-4.1-ndb

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

The problem reported is a compile bug,
reported by the development GCC team with GCC 4.2.

The original issue can no longer be reproduced in MySQL 5.1,
since the configure script no longer define HAVE_ATOMIC_ADD,
which caused the Linux atomic functions to be used (and cause a problem
with an invalid cast).

This patch implements some code cleanup for 5.1 only, which was identified
during the investigation of this issue.

With this patch, statistics maintained in THD::status_var are by definition
owned by the running thread, and do not need to be protected against race
conditions. These statistics are maintained by the status_var_* helpers,
which do not require any lock.