This is a null merge because it only contains InnoDB changes that
originated in mysql-5.1-innodb and have been manually ported into
mysql-5.5-innodb.

This is a manual merge from mysql-5.1-innodb of:

  revision-id: vasil.dimov@oracle.com-20100930102618-s9f9ytbytr3eqw9h
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  timestamp: Thu 2010-09-30 13:26:18 +0300
  message:
    Fix a potential bug when using __sync_lock_test_and_set()

    TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...)

    it is not documented what happens if the two arguments are of different
    type like it was before: the first one was lock_word_t (byte) and the
    second one was 1 or 0 (int).

    Approved by:	Marko (via IRC)

This is a manual merge from mysql-5.1-innodb of:

  revno: 3618
  revision-id: vasil.dimov@oracle.com-20100930124844-yglojy7c3vaji6dx
  parent: vasil.dimov@oracle.com-20100930102618-s9f9ytbytr3eqw9h
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  branch nick: mysql-5.1-innodb
  timestamp: Thu 2010-09-30 15:48:44 +0300
  message:
    Fix Bug#56340 innodb updates index stats too frequently after non-index updates

    This is a simple optimization issue. All stats are related to only indexed
    columns, index size or number of rows in the whole table. UPDATEs that touch
    only non-indexed columns cannot affect stats and we can avoid calling the
    function row_update_statistics_if_needed() which may result in unnecessary I/O.

    Approved by:	Marko (rb://466)

In addition to the above message: we know that
row_update_cascade_for_mysql() (the other place where
row_update_statistics_if_needed is called) always updates indexed
columns (FK-related), so there is no need to add this cond there.

inline perl in the test.

in the MDL deadlock detector".

It is no longer needed as a better fix for this bug has
been pushed.

This is a simple optimization issue. All stats are related to only indexed
columns, index size or number of rows in the whole table. UPDATEs that touch
only non-indexed columns cannot affect stats and we can avoid calling the
function row_update_statistics_if_needed() which may result in unnecessary I/O.

Approved by:	Marko (rb://466)

TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...)

it is not documented what happens if the two arguments are of different
type like it was before: the first one was lock_word_t (byte) and the
second one was 1 or 0 (int).

Approved by:	Marko (via IRC)

detector" that doesn't introduce bug #56715 "Concurrent
transactions + FLUSH result in sporadical unwarranted
deadlock errors".

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

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

The previous patch tried to workaround this problem by not
allowing the 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
was reported. As a result it has introduced bug #56715.

This patch solves this problem in a different way.
It introduces a new rw_pr_lock_t implementation to be used
by MDL subsystem instead of one based on Linux rwlocks or
our own rwlock implementation. This new implementation
never allows situation in which an rwlock is rd-locked and
there is a blocked pending rd-lock. Thus the situation which
has caused this bug becomes impossible with this implementation.

Due to fact that this implementation is optimized for
wr-lock/unlock scenario which is most common in the MDL
subsystem it doesn't introduce noticeable performance
regressions in sysbench tests. Moreover it significantly
improves situation for POINT_SELECT test when many
connections are used.

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.
This patch also doesn't include a test for bug #56715
"Concurrent transactions + FLUSH result in sporadical
unwarranted deadlock errors" as it takes too much time to
be run as part of normal test-suite runs.

config.h.cmake:
  We no longer need to check for presence of
  pthread_rwlockattr_setkind_np as we no longer
  use Linux-specific implementation of rw_pr_lock_t
  which uses this function.
configure.cmake:
  We no longer need to check for presence of
  pthread_rwlockattr_setkind_np as we no longer
  use Linux-specific implementation of rw_pr_lock_t
  which uses this function.
configure.in:
  We no longer need to check for presence of
  pthread_rwlockattr_setkind_np as we no longer
  use Linux-specific implementation of rw_pr_lock_t
  which uses this function.
include/my_pthread.h:
  Introduced new implementation of rw_pr_lock_t.
  Since it never allows situation in which rwlock is rd-locked
  and there is a blocked pending rd-lock it is not affected by
  bug #56405 "Deadlock in the MDL deadlock detector".
  This implementation is also optimized for wr-lock/unlock
  scenario which is most common in MDL subsystem. So it doesn't
  introduce noticiable performance regressions in sysbench tests
  (compared to old Linux-specific implementation). Moreover it
  significantly improves situation for POINT_SELECT test when
  many connections are used.
  As part of this change removed try-lock part of API for
  this type of lock. It is not used in our code and it would
  be hard to implement correctly within constraints of new
  implementation.
  Finally, removed support of preferring readers from
  my_rw_lock_t implementation as the only user of this
  feature was old rw_pr_lock_t implementation.
include/mysql/psi/mysql_thread.h:
  Removed try-lock part of prlock API.
  It is not used in our code and it would be hard
  to implement correctly within constraints of new
  prlock implementation.
mysys/thr_rwlock.c:
  Introduced new implementation of rw_pr_lock_t.
  Since it never allows situation in which rwlock is rd-locked
  and there is a blocked pending rd-lock it is not affected by
  bug #56405 "Deadlock in the MDL deadlock detector".
  This implementation is also optimized for wr-lock/unlock
  scenario which is most common in MDL subsystem. So it doesn't
  introduce noticiable performance regressions in sysbench tests
  (compared to old Linux-specific implementation). Moreover it
  significantly improves situation for POINT_SELECT test when
  many connections are used.
  Also removed support of preferring readers from
  my_rw_lock_t implementation as the only user of this
  feature was old rw_pr_lock_t implementation.

with CMake 2.8.3 builtin macro

This patch moves the regression test from variables.test to
variables_debug.test as the debug system variable is not 
available on release builds.

InnoDB Plugin 1.0.12 has been released with MySQL 5.1.51.

This crash occured if the same debug trace file was closed twice,
leading to the same memory being free'd twice. This could occur
if the "debug" server system variable refered to the same trace
file in both global and session scope.

Example of an order of events that would lead to a crash:
1) Enable debug tracing to a trace file (global scope)
2) Enable debug tracing to the same trace file (session scope)
3) Reset debug settings (global scope)
4) Reset debug settings (session scope)

This caused a crash because the trace file was, by mistake, closed
in 3), leading to the same memory being free'd twice when the file
was closed again in 4).

Internally, the debug settings are stored in a stack, with session
settings (if any) on top and the global settings below. Each connection
has its own stack. When a set of settings is changed, it must be 
determined if its debug trace file is to be closed. Before, this was done
by only checking below on the settings stack. So if the global settings
were changed, an existing debug trace file reference in session settings
would be missed. This caused the file to be closed even if it was in use,
leading to a crash later when it was closed again.

This patch fixes the problem by preventing the trace file from being shared
between global and session settings. If session debug settings are set without
specifying a new trace file, stderr is used for output. This is a change
in behaviour and should be reflected in the documentation.

Test case added to variables.test.

  ------------------------------------------------------------
  revno: 3615
  revision-id: vasil.dimov@oracle.com-20100928081234-22qbm6cwht521484
  parent: vasil.dimov@oracle.com-20100928063833-snn6cjwgksa6gk3b
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  branch nick: mysql-5.1-innodb
  timestamp: Tue 2010-09-28 11:12:34 +0300
  message:
    Silence a GCC warning about reaching the end of non-void func
    
    Spotted by:	Marko

Spotted by:	Marko

Spotted by:	Davi Arnaut

per-file comments:
  mysql-test/t/log_tables_debug.test
        This test shouldn't be run at the embedded server.

Use UNINIT_VAR workaround instead of LINT_INIT. The former can
also be used to silence false-positives in non-debug builds as
it actually does not cause new code to be generated.

Use UNINIT_VAR workaround instead of LINT_INIT. The former is
also used in non-debug builds as it doesn't cause changes.

argument of inline_mysql_mutex_init in sql_base.cc.

When initializing LOCK_dd_owns_lock_open mutex pass
correct PSI key instead of NULL value.

mysql-test/suite/perfschema/r/dml_setup_instruments.result:
  Updated test results after adding P_S instrumentation
  for LOCK_dd_owns_lock_open.
sql/sql_base.cc:
  When initializing LOCK_dd_owns_lock_open mutex pass
  correct PSI key instead of NULL value.

Temporarily disable strict aliasing warnings in order to get
wider coverage for optimized builds. Once the violations are
fixed and false-positives silenced, this flag should be removed.

sql/sql_cache.cc:
  Added include of send_data_in_chunks() definiton when macros EMBEDDED_LIBRARY is on.

After the patch for Bug#54579, multi inserts done with INSERT DELAYED
are binlogged as normal INSERT. During processing of the statement,
a new query string without the DELAYED keyword is made. The problem
was that this new string was incorrectly made when the INSERT DELAYED
was part of a prepared statement - data was read outside the allocated
buffer.

The reason for this bug was that a pointer to the position of the
DELAYED keyword inside the query string was stored when parsing the
statement. This pointer was then later (at runtime) used (via pointer
subtraction) to find the number of characters to skip when making a
new query string without DELAYED. But when the statement was re-executed
as part of a prepared statement, the original pointer would be invalid
and the pointer subtraction would give a wrong/random result.

This patch fixes the problem by instead storing the offsets from the
beginning of the query string to the start and end of the DELAYED 
keyword. These values will not depend on the memory position
of the query string at runtime and therefore not give wrong results
when the statement is executed in a prepared statement.

This bug was a regression introduced by the patch for Bug#54579.

No test case added as this bug is already covered by the existing
binlog.binlog_unsafe test case when running with valgrind.