Follow-up: don't call pthread_join() on Windows
This change only valid for 5.1

Added counts of skipped test, inclusing how many by test itself
Also fixed misspelling in the (hitherto unused) variable name

When stepping backward to end of `` expression, check for illegal chars

Bug #55546 mysqltest fails to create a new thread on HPUX
Missing call to pthread_join(), in embedded mode
This independently solves both problems, see 55426 for details.
Addendum: cannot test against a pthread_t, adds boolean flag instead

This is not the final merge!

Moved an init_dynamic_string() from before to after potential die()

After installation from RPM, server is run under root, not mysql user

The problem was that in the cmake way of building
the variable "MYSQLD_USER" was not set and propagated.
In the script "mysqld_safe" its value is used as the
name of the user who should run the server process.

The fix is to explicitly set this variable to "mysql"
and propagate it in the build process.
It was analyzed and proposed by Jonathan Perkin. 

MDL deadlock detector".

Deadlock could have occurred when workload containing mix
of DML, DDL and FLUSH TABLES statements affecting same
set of tables was executed in heavily concurrent environment.

This deadlock occurred when several connections tried to
perform deadlock detection in metadata locking subsystem.
The first connection started traversing wait-for graph,
encountered sub-graph representing wait for flush, acquired
LOCK_open and dived into sub-graph inspection. When it has
encounterd sub-graph corresponding to wait for metadata lock
and blocked while trying to acquire rd-lock on
MDL_lock::m_rwlock (*) protecting this subgraph, since some
other thread had wr-lock on it. When this wr-lock was released
it could have happened (if there was other pending wr-lock
against this rwlock) that rd-lock from the first connection
was left unsatisfied but at the same time new rd-lock request
from the second connection sneaked in and was satisfied (for
this to be possible second rd- request should come exactly
after wr-lock is released but before pending wr-lock manages
to grab rwlock, which is possible both on Linux and in our
own rwlock implementation). If this second connection
continued traversing wait-for graph and encountered sub-graph
representing wait for flush it tried to acquire LOCK_open
and thus deadlock was created.

This patch tries to workaround this problem but not allowing
deadlock detector to lock LOCK_open mutex if some other thread
doing deadlock detection already owns it and current search
depth is greater than 0. Instead deadlock is reported.

Other possible solutions are either known to have negative
effects on performance or require much more time for proper
implementation and testing.

No test case is provided as this bug is very hard to repeat
in MTR environment but is repeatable with the help of RQG
tests.

sql/mdl.cc:
  Moved Deadlock_detection_visitor::m_current_search_depth to
  parent class to make it available in
  TABLE_SHARE::visit_subgraph().
  Added MDL_wait_for_graph_visitor::abort_traversal() method
  which allows to abort traversal of a wait-for graph and
  report a deadlock.
sql/mdl.h:
  Moved Deadlock_detection_visitor::m_current_search_depth to
  parent class to make it available in
  TABLE_SHARE::visit_subgraph().
  Added MDL_wait_for_graph_visitor::abort_traversal() method
  which allows to abort traversal of a wait-for graph and
  report a deadlock.
sql/sql_base.cc:
  Added dd_owns_lock_open counter and mutex protecting it to
  track number of connections which do deadlock detection and
  own or try to acquire LOCK_open.
sql/sql_base.h:
  Added dd_owns_lock_open counter and mutex protecting it to
  track number of connections which do deadlock detection and
  own or try to acquire LOCK_open.
sql/table.cc:
  Workaround bug #56405 but not allowing MDL deadlock detector
  to lock LOCK_open mutex if some other thread doing deadlock
  detection already owns it and current search depth is greater
  than 0. Instead report deadlock.

The problem was not caused by a change in the client,
rather by the tests using the Windows built-in "echo"
and not the one built by MySQL.
This again happened because the binary was missing in the package,
caused by the wrong macro being used to build it in "cmake".

Original changeset:
------------------------------------------------------------
revno: 3186
revision-id: davi.arnaut@oracle.com-20100831142822-2qhufn3hho4xqr4p
parent: gshchepa@mysql.com-20100830222201-ie7n43mjy4irlllk
committer: Davi Arnaut <davi.arnaut@oracle.com>
branch nick: mysql-5.5-merge
timestamp: Tue 2010-08-31 11:28:22 -0300
message:
  Bug#55846: Link tests fail on Windows - my_compiler.h missing
  
  Make the my_compiler.h header, like my_attribute.h, part of
  the distribution. This is required due to the dependency of
  the former on the latter (which can undefine __attribute__).
------------------------------------------------------------

Original changeset:
------------------------------------------------------------
revno: 3197
revision-id: alik@sun.com-20100831135426-h5a4s2w6ih1d8q2x
parent: magnus.blaudd@sun.com-20100830120632-u3xzy002mdwueli8
committer: Alexander Nozdrin <alik@sun.com>
branch nick: mysql-5.5-bugfixing
timestamp: Tue 2010-08-31 17:54:26 +0400
message:
  Bug#55980 Character sets: supplementary character _bin ordering is wrong
  
  Problem:
  - ORDER BY for utf8mb4_bin, utf16_bin and utf32_bin returned
    results in a wrong order, because old functions
    (supporting only BMP range) were used to handle these collations.
  - Additionally, utf16_bin did not sort supplementary characters
    between U+D700 and U+E000, as WL#1213 specification specified.
------------------------------------------------------------

```---------------------------------------------------------
revno: 3124
revision-id: dlenev@mysql.com-20100831090419-rzr5ktekby2gspm1
parent: alik@sun.com-20100827083901-x4wvtc10u9p7gcs9
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-5.5-rt-56137
timestamp: Tue 2010-08-31 13:04:19 +0400
message:
  Bug #56137 "Assertion `thd->lock == 0' failed on upgrading 
  from 5.1.50 to 5.5.6".
  
  Debug builds of the server aborted due to an assertion
  failure when DROP DATABASE statement was run on an
  installation which had outdated or corrupt mysql.proc table.
  Particularly this affected the mysql_upgrade tool which is
  run as part of 5.1 to 5.5 upgrade.
  
  The problem was that sp_drop_db_routines(), which was invoked
  during dropping of the database, could have returned without
  closing and unlocking mysql.proc table in cases when this
  table was not up-to-date with the current server. As a result
  further attempt to open and lock the mysql.event table, which
  was necessary to complete dropping of the database, ended up
  with an assert.
  
  This patch solves this problem by ensuring that
  sp_drop_db_routines() always closes mysql.proc table and
  releases metadata locks on it. This is achieved by changing
  open_proc_table_for_update() function to close tables and
  release metadata locks acquired by it in case of failure.
  This step also makes behavior of the latter function
  consistent with behavior of open_proc_table_for_read()/
  open_and_lock_tables().
  
  
  Test case for this bug was added to sp-destruct.test.
```

---------------------------------------------------------

Added --force-restart

            "Access compatibility" syntax

The "wild" "DELETE FROM table_name.* ... USING ..." syntax
for multi-table DELETE statements is documented but it was
lost in the fix for the bug 30234.

The table_ident_opt_wild parser rule has been added
to restore the lost syntax.


mysql-test/r/delete.result:
  Test case for bug #53034.
mysql-test/t/delete.test:
  Test case for bug #53034.
sql/sql_yacc.yy:
  Bug #53034: Multiple-table DELETE statements not accepting
              "Access compatibility" syntax
  
  The table_ident_opt_wild parser rule has been added
  to restore the lost syntax.
  Note: simple extending of table_ident with opt_wild in
  the table_alias_ref rule is not acceptable, because
  a) it adds one conflict more and b) this conflict resolves
  in the inappropriate way.

Allow --testcase-timeout=<mins> to be set in .opt file for test

so test case has to be updated.