detector". This patch addresses performance regression in OLTP_RO/MyISAM
test on Windows introduced by the fix for bug #56405. Thus it makes
original patch acceptable as a solution for bug #56585 "Slowdown of
readonly sysbench benchmarks (e.g point_select) on Windows 5.5".

With this patch, MySQL will use native Windows condition variables and 
reader-writer locks  if  they are supported by the OS.

This speeds up MyISAM and the effect comes mostly from using native
rwlocks. Native conditions improve scalability with higher number of 
concurrent users in other situations, e.g for prlocks.

Benchmark numbers for this patch as measured on Win2008R2 quad
core machine are attached to the bug report.
( direct link http://bugs.mysql.com/file.php?id=15883 )

Note that currently we require at least Windows7/WS2008R2 for 
reader-writer locks, even though native rwlock is available also on Vista.
Reason is that "trylock" APIs are missing on Vista, and trylock is used in
the server (in a single place in query cache).

While this patch could have been written differently, to enable the native
rwlock optimization also on Vista/WS2008 (e.g using native locks everywhere
but portable implementation in query cache), this would come at the 
expense of the code clarity, as it would introduce a new  "try-able" rwlock
type, to handle Vista case.

Another way to improve performance for the special case 
(OLTP_RO/MYISAM/Vista) would be to eliminate "trylock" usage from server,
 but this is outside of the scope here.


Native conditions variables are used beginning with Vista though the effect
of using condition variables alone is not measurable in this benchmark.
But when used together with native rwlocks on Win7, native conditions improve 
performance in high-concurrency OLTP_RO/MyISAM (128 and more sysbench 
users).

conflicts:
   conflict      dbug/dbug.c
   conflict      sql/sql_load.cc

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)

LOAD DATA into partitioned MyISAM table

Problem was that both partitioning and myisam
used the same table_share->mutex for different protections
(auto inc and repair).

Solved by adding a specific mutex for the partitioning
auto_increment.

Also adding destroying the ha_data structure in
free_table_share (which is to be propagated
into 5.5).

This is a 5.1 ONLY patch, already fixed in 5.5+.

           REBUILD PARTITION under LOCK TABLE

Collapsed patch including updates from the reviews.

In case of failure in ALTER ... PARTITION under LOCK TABLE
the server could crash, due to it had modified the locked
table object, which was not reverted in case of failure,
resulting in a bad table definition used after the failed
command.

Solved by instead of altering the locked table object and
its partition_info struct, creating an internal temporary
intermediate table object used for altering,
just like the non partitioned mysql_alter_table.
So if an error occur before the alter operation is complete,
the original table is not modified at all.
But if the alter operation have succeeded so far that it
must be completed as whole,
the table is properly closed and reopened.
(The completion on failure is done by the ddl_log.)

mysql-test/suite/parts/inc/partition_fail.inc:
  Added tests under LOCK TABLE
mysql-test/suite/parts/r/partition_debug_innodb.result:
  Updated results
mysql-test/suite/parts/r/partition_debug_myisam.result:
  Updated results
mysql-test/suite/parts/r/partition_special_innodb.result:
  updated result
mysql-test/suite/parts/t/partition_special_innodb.test:
  changing comment, since this patch also fixes this.
sql/sql_partition.cc:
  Added TODO, to use DBUG_SUICIDE() instead of abort()
  to avoid core-files on expected crashes.
  Removed unused arguments to fast_end_partition.
  Opening a intermediate table in prep_alter_part_table, instead of altering
  (a possible locked) normally opened table.
  That way we do not have to do anything more than close
  the intermediate table on error,
  leaving the ordinary table opened and locked.
  Also making sure that the intermediate table are
  closed/destroyed on failure. If no error occur
  it is later destroyed in the end of fast_alter_partition_table.
  Added ha_external_lock to make sure MyISAM flushed the index file
  after copying the partitions.
  This also leads to removal of the special close and removal from
  the table cache for other instances of the table.
sql/sql_partition.h:
  Changed the arguments for prep_alter_part_table and
  fast_alter_partition_table to use an intermediate table
  instead of altering a (possibly locked) normal table.
sql/sql_table.cc:
  Using an intermediate table created in prep_alter_part_table
  to be used in fast_alter_partition_table, also closing/destroying
  it on failure.

Added sanity check, similar to the one preventing send without reap

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.

Bug#57113: ha_partition::extra(ha_extra_function):
            Assertion `m_extra_cache' failed

Fix for bug#55458 included DBUG_ASSERTS causing
debug builds of the server to crash on
another multi-table update.

Removed the asserts since they where wrong.
(updated after testing the patch in 5.5).

mysql-test/r/partition.result:
  updated result
mysql-test/t/partition.test:
  Added test for bug#57113
sql/ha_partition.cc:
  Removed the assert for m_extra_cache when
  ::extra(HA_PREPARE_FOR_UPDATE) was called.

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)