Before this fix, the performance schema file instrumentation would treat:
- a relative path to a file
- an absolute path to the same file
as two different files.

This would lead to:
- separate aggregation counters
- file leaks when a file is removed.

With this fix, a relative and absolute path are resolved to the same file instrument.

into mysql-next-4284 tree.

mysql-next-4284.

mysql-next-4284 tree.

The problem was that ALTER TABLE on a merge table which was locked 
using LOCK TABLE ... WRITE, by mistake gave 
ER_TABLE_NOT_LOCKED_FOR_WRITE.

During opening of the table to be ALTERed, open_table() tried to
get an upgradable metadata lock. In LOCK TABLEs mode, this lock
must already exist (i.e. taken by LOCK TABLE) as new locks of this
type cannot be acquired for fear of deadlock. So in LOCK TABLEs
mode, open_table() tried to find an existing upgradable lock for
the table to be altered.

The problem was that open_table() also tried to find upgradable
metadata locks for children of merge tables even if no such
locks are needed to execute ALTER TABLE on merge tables.

This patch fixes the problem by making sure that open tables code
only searches for upgradable metadata locks for the merge table
and not for the merge children tables. 

The patch also fixes a related bug where an upgradable metadata
lock was aquired outside of LOCK TABLEs mode even if the table in
question was temporary. This bug meant that LOCK TABLES or DDL on
temporary tables by mistake could be blocked/aborted by locks held
on base tables with the same table name by other connections.

Test cases added to merge.test and lock_multi.test.

Attempts to execute RESET statements within a transaction that
had acquired metadata locks, led to an assertion failure on 
debug servers. This bug didn't cause any problems on release
builds.

The triggered assert is designed to check that caches are not
flushed or reset while having active transactions. It is triggered
if acquired metadata locks exist that are not from LOCK TABLE or
HANDLER statements.

In this case it was triggered by RESET QUERY CACHE while having
an active transaction that had acquired locks. The reason the
assertion was triggered, was that RESET statements, unlike the
similar FLUSH statements, was not causing an implicit commit.

This patch fixes the problem by making sure RESET statements
commit the current transaction before executing. The commit
causes acquired metadata locks to be released, preventing the
assertion from being triggered.

Incompatible change: This patch changes RESET statements so
that they cause an implicit commit.

Test case added to query_cache.test.

The problem was incorrect escaping used inside a strnig : in \"$MYSQLD\" was written as "\MYSQL\" 
(backslash and quote characters transposed), when defining FIND_PROC  variable for BSD or SysV
style "ps" command-

Additionally fixed obvious code duplication and random naming in CHECK_PID test.

           bool MDL_context::try_acquire_lock(MDL_request*)

This assert was triggered in the following way:
1) HANDLER OPEN t1 from connection 1
2) DROP TABLE t1 from connection 2. This will block due to the metadata lock
held by the open handler in connection 1.
3) DML statement (e.g. INSERT) from connection 1. This will close the table
opened by the HANDLER in 1) and release its metadata lock. This is done due
to the pending exclusive metadata lock from 2). 
4) DROP TABLE t1 from connection 2 now completes and removes table t1.
5) HANDLER READ from connection 1. Since the handler table was closed in 3),
the handler code will try to reopen the table. First a new metadata lock on
t1 will be granted before the command fails since the table was removed in 4).
6) HANDLER READ from connection 1. This caused the assert.

The reason for the assert was that the MDL_request's pointer to the lock
ticket was not reset when the statement failed. HANDLER READ then tried to
acquire a lock using the same MDL_request object, triggering the assert.
This bug was only noticeable on debug builds and did not cause any problems
on release builds.

This patch fixes the problem by assuring that the pointer to the metadata 
lock ticket is reset when reopening of handler tables fails.

Test case added to handler.inc

Crash happens in dlopen() code when trying to load the library. Crash does not happen when library is 
not DTrace instrumented . Additionally, crash does not happen with default Solaris 10 GCC 3.4.3 and
it does not happen if main executable is instrumented.

So , just check for this specific situation (32 bit, GCC3.4.6 , Solaris) and disable Dtrace in shared libraries.
We have only single plugin so far that is instrumented (ha_example)

    Two problems addressed here:
       Embedded-server linking failure.
          sql/sys_vars.cc absents in the libmysqld/CMakeLists.txt
       The PERFORMANCE_SCHEMA-related failure of the embedded-server compilation.
          We try to disable the PERFORMANCE_SCHEMA in the embedded server
          as it's considered useless there. But we do it in wrong way as
          we only disable header's links to the PF, not the PF's library itself.
          So on Unix-ex the embedded library still contains the PF code and
          grows bigger with no reason. On Windows that just fails to compile.
             
per-file comments:
  include/my_global.h
Bug#41103      6.0 Windows embedded-server tests fail
      No PERFORMANCE_SCHEMA disabling in the embedded server. User can
      just use the --without-perfschema-engine-plugin option to exclude it
      from the compilation.

-lthread works fine in most cases, but at least with gcc 3.4.6 on x86, dlopen() crashes when libpthread is not used. 
Note : the workaround existed prior and did not work  since CMAKE_THREADS_LIBS_INIT was already
 in cache.  Now, use SET(.. CACHE FORCE)  to overwrite the cached value.

 - Remove INSTALL-BINARY from installed docs directory, we provide a copy
   in the root directory (but perhaps this should be revisited later).

 - Disable audit_null and daemon_example plugins.

 - Fix the docs directory.

 - Remove mysql-test/Makefile.in

 - Build and install mysql_tzinfo_to_sql

 - Remove share/charsets/languages.html

In the worst case possible scenario (no bzr, in-source build),
make dist produced a package that compiled ok with autotools
but failed to package because extra make_binary_distribution was
found in source package and was not built. make_binary_distribution
contained paths of the build machine.

Fix:  exclude some scripts that are produced in cmake build. 
Note that there is no good general fix for it in this specific scenario.
it is advisable to build source packages out of source or in bzr repo.

actually "system"), --with-ssl should be "bundled".

Fixes error on sol-gcc-x86, where build machine had  openssl but not
the test box.

This patch prevents system threads and system table accesses from
using user-specified values for "lock_wait_timeout". Instead all
such accesses are done using the default value (1 year).

This prevents background tasks (such as replication, events, 
accessing stored function definitions, logging, reading time-zone
information, etc.) from failing in cases where the global value
of "lock_wait_timeout" is set very low.

The patch also simplifies the open tables API. Rather than adding
another convenience function for opening and locking system tables,
this patch removes most of the existing convenience functions for
open_and_lock_tables_derived(). Before, open_and_lock_tables() was
a convenience function that enforced derived tables handling, while
open_and_lock_tables_derived() was the main function where derived
tables handling was optional. Now, this convencience function is
gone and the main function is renamed to open_and_lock_tables(). 

No test case added as it would have required the use of --sleep to
check that system threads and system tables have a different timeout
value from the user-specified "lock_wait_timeout" system variable.

HAVE_IBGCC_ATOMIC_BUILTINS=>HAVE_IB_GCC_ATOMIC_BUILTINS.
Due to the typo, detection of atomics was broken. 
It also lead to valgrind error during shutdown 
(access to freed memory),which is likely present 
in all builds where atomics are not used.

Backport to 5.5.99

Reason: implementation of send/reap in mysqltest uses the same "embedded" connection in a thread different from current, so thread stack has to change when connection is used in different  OS thread..

Backport to 5.5.99

It appears that stack overflow checks for recusrive stored procedure
calls, that run in the normal server, did not work in embedded and were
 dummified with preprocessor magic( #ifndef EMBEDDED_SERVER ).
      
 The fix is to remove ifdefs, there is no reason not to run overflow checks
 and crash in deeply recursive calls. 
      
 Note: Start of the stack (thd->thread_stack variable) in embedded is not
necessarily exact but stil provides the best guess. Unless the caller of 
mysql_read_connect()   is already deep in the stack, thd->thread_stack 
variable should approximate stack  start address well.