Separating out sub-test.

Be more explicit about path to (potential) plugin tests dirs

             SECONDARY INDEX IN INNODB

This is a follow-up patch.

This patch moves part of the new test coverage to a test
file that is only run on debug builds since it used debug-
only features and therefore broke the test case on
release builds.

Sets INSTALL_PLUGINTESTDIR if any plugin/*/tests exist

innodb_prefix_index_liftedlimit.test used for functional testing of increase in prefix index limit

             SECONDARY INDEX IN INNODB

The patches for Bug#11751388 and Bug#11784056 enabled concurrent
reads while creating secondary indexes in InnoDB. However, they
introduced a regression. This regression occured if ALTER TABLE
failed after the index had been added, for example during the
lock upgrade needed to update .FRM. If this happened, InnoDB
and the server got out of sync with regards to which indexes
actually existed. Therefore the patch for Bug#11815600 again
disabled concurrent reads.

This patch re-enables concurrent reads. The original regression
is fixed by splitting the ADD INDEX operation into two parts.
First the new index is created but not made active. This is
done while concurrent reads are allowed. The second part of
the operation makes the index active (or reverts the change).
This is done after lock upgrade, which prevents the original
regression.

In order to implement this change, the patch changes the storage
API for in-place index creation. handler::add_index() is split
into two functions, handler_add_index() and
handler::final_add_index(). The former for creating indexes without
making them visible and the latter for commiting (i.e. making
visible) new indexes or reverting the changes.

Large parts of this patch were written by Marko Mäkelä.

Test case added to innodb_mysql_lock.test.

With this change, the index prefix column length lifted from 767 bytes
to 3072 bytes if "innodb_large_prefix" is set to "true".

rb://603 approved by Marko

mtr_start(): Declare the mtr memory area uninitialized in Valgrind
before initializing the fields.

mtr_commit(): Declare everything uninitialized except
mtr->start_lsn, mtr->end_lsn and mtr->state.

The test case problem stemmed from the fact that a debug sync
signal is a global variable that persists until overwritten
by a new signal. This means that if two different signals
are raised in sequence, a thread waiting for the first signal
might miss it if the second signal sets the global variable
before the thread wakes up.

The solution is to deliver a subsequent signal only after the
waiting thread has received it.

mysql-test/t/query_cache_debug.test:
  Wait for signal to be delivered.

Added reading from plugin.defs files under plugins/*

The problem is that clients implementing the 4.0 version of the
protocol (that is, mysql-4.0) do not null terminate a string
at the end of the authentication packet. These clients denote
the end of the string with the end of the packet.

Although this goes against the documented (see MySQL Internals
ClientServer Protocol wiki) description of the protocol, these
old clients still need to be supported.

The solution is to support the documented and actual behavior
of the clients. If a client is using the pre-4.1 version of
the protocol, the end of a string in the authentication packet
can either be denoted with a null character or by the end of
the packet. This restores backwards compatibility with old
clients implementing either the documented or actual behavior.

sql/password.c:
  The scrambled message, as provided by the user, might not be
  properly null terminated. If this is the case, uninitialized
  memory past the end of the buffer could theoretically be
  accessed. To ensure that this is never the case, copy the
  scrambled message over to a null terminated auxiliar buffer.
sql/sql_connect.cc:
  Use different execution paths to read strings depending on the
  protocol being used. If version 4.0 of the protocol is used,
  end of string can be denoted with a NUL character or by the
  end of the packet.
  
  If there are not enough bytes left after the current position
  of the buffer to satisfy the current string, the string is
  considered to be empty. This is required because old clients
  do not send the password string field if the password is empty.

Do this in the common plugin.cmake but only if running in PB2
  (If done in manual builds it would create a bzr diff)

The problem is that although AIX implements bzero, its prototype
is not declared by default. Since AC_CHECK_FUNC(bzero) succeeds
even though a prototype is not declared, this breaks compilation
in C++ files where a prototype is required.

The solution is to only use bzero if a prototype is also declared.

configure.in:
  Check if bzero is declared. No need to specify the includes,
  unisted.h and strings.h are already part of AC_INCLUDES_DEFAULT.

will create multiple running events.

A CREATE IF NOT EXIST on an event that existed and was enabled caused
multiple instances of the event to run. Disabling the event didn't  help.
If the event was  dropped, the event stopped running, but when created
again, multiple instances of the event were still running. The only way
to get out of this situation was  to restart the server.

The problem was that Event_db_repository::create_event() didn't return
enough information to discriminate between situation when event didn't
exist and was created and when event did exist and was not created
(but a warning was emitted). As result in the latter case event
was added to in-memory queue of events second time. And this led to
unwarranted multiple executions of the same event.

The solution is to add out-parameter to Event_db_repository::create_event()
method which will signal that event was not created because it already
exists and so it should not be added to the in-memory queue.


mysql-test/r/events_bugs.result:
  Added results for test for Bug#12546938.
mysql-test/t/events_bugs.test:
  Added test for Bug#12546938.
sql/event_db_repository.cc:
  Event_db_repository::create_event was modified: set newly added out-parameter
  event_already_exists to true value if event wasn't created because event
  already existed and IF NOT EXIST clause was present.
sql/event_db_repository.h:
  Added out-parameter 'event_already_exists' to create_event() method.
sql/events.cc:
  Events::create_event was modified: insert new element into
  event queue only if event was actually created.

HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ...
   READ.

Unfortunately both of these approaches have drawbacks which make
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.5 version of this patch switch from read lock to write
lock is done on SQL-layer.

mysql-test/suite/innodb/r/innodb_mysql.result:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
sql/sql_parse.cc:
  Since a temporary table locked by LOCK TABLES can be updated even
  if it was only locked for read we always request TL_WRITE locks
  for such tables at LOCK TABLES time. This allows to avoid 
  discrepancy between locks acquired at LOCK TABLES time and by
  a statement executed under LOCK TABLES. Such a discrepancy has
  caused problems for InnoDB storage engine.
  
  To support this change a part of code implementing LOCK TABLES 
  has been moved to a helper function.

INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE,
TABLE LOCK" into 5.5 tree. 5.5 version of fix will be
committed and pushed separately.

HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The 
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock 
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a 
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will 
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ... 
   READ.

Unfortunately both of these approaches have drawbacks which make 
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.1 version of this patch switch from read lock to write
lock is done inside of InnoDBs handler methods as doing it on 
SQL-layer causes compatibility troubles with FLUSH TABLES WITH
READ LOCK.

mysql-test/suite/innodb/r/innodb_mysql.result:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
storage/innobase/handler/ha_innodb.cc:
  Assume that a temporary table locked by LOCK TABLES can be updated
  even if it was only locked for read and therefore an X-lock should 
  be always requested for such tables.
storage/innodb_plugin/handler/ha_innodb.cc:
  Assume that a temporary table locked by LOCK TABLES can be updated
  even if it was only locked for read and therefore an X-lock should 
  be always requested for such tables.

Two conflicts resolved manually:
Text conflict in sql/log.cc
Text conflict in sql/mysqld.cc

Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order.
The correct order is first LOCK_thread_count and then LOCK_log. This function
does it the other way around. This leads to deadlock when run in parallel
with a thread that takes the two locks in correct order. For example, a thread
that disconnects will take the locks in the correct order.
Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs:
first LOCK_thread_count and then LOCK_log.


mysql-test/suite/binlog/r/binlog_reset_master.result:
  added result file
mysql-test/suite/binlog/t/binlog_reset_master.test:
  Added test case that demonstrates deadlock because of wrong mutex order.
  The deadlock is between two threads:
   - RESET MASTER acquires mutexes in wrong order.
   - client thread shutdown code acquires mutexes in right order.
  Actually, this test case does not produce deadlock in 5.1, probably
  the client thread shutdown code does not hold both mutexes at the same
  time. However, the bug existed in 5.1 (mutexes are taken in the wrong
  order) so we push the test case to 5.1 too, to prevent future
  regressions.
sql/log.cc:
  Change mutex acquisition to the correct order:
  first LOCK_thread_count, then LOCK_log.
sql/mysqld.cc:
  Add debug code to synchronize test case.

Assertion happens due to missing NULL value check in
Item_func_round::fix_length_and_dec() function.
The fix: added NULL value check for second parameter.


mysql-test/r/func_math.result:
  test case
mysql-test/t/func_math.test:
  test case
sql/item_func.cc:
  added NULL value check for second parameter.

Execution of platforms tests are slow/flaky when building on windows.
in PB:mysql-next-mr-opt-team on 2011-05-18 for win x86 debug_max, i see:
-- Looking for FIONREAD
-- Looking for FIONREAD - found
and the build fails.

sql/sql_show.cc:
  Restored DEBUG_SYNC point missed during merge 5.1->5.5

Not for test itself but because it procuces large number of warnings,
  and this may take >90s to filter on slow boxes

Replace global check_timeout with one that calls testcase_timeout for the test

Added --with-gcov option to configure.pl and use that from SETUP.sh

BUG#12578441, reintroduced thd->cleanup() in unlink_thd, removed by mistake, added private interface to this function