and also applying 5.1-ss6355

Detailed revision comments:

r6324 | jyang | 2009-12-17 06:54:24 +0200 (Thu, 17 Dec 2009) | 8 lines
branches/5.1: Fix bug #47814 - Diagnostics are frequently not
printed after a long lock wait in InnoDB. Separate out the 
lock wait timeout check thread from monitor information
printing thread.

rb://200 Approved by Marko.

r6349 | marko | 2009-12-22 11:09:54 +0200 (Tue, 22 Dec 2009) | 3 lines
branches/5.1: lock_print_info_summary(): Remove a reference to
innobase_mysql_end_print_arbitrary_thd() that should have been
removed in r6347 when removing the function.

r6350 | marko | 2009-12-22 11:11:09 +0200 (Tue, 22 Dec 2009) | 1 line
branches/5.1: Remove an obsolete declaration of LOCK_thread_count.

At the end of execution top level join execution
we cleanup this join with true argument.
It leads to underlying join cleanup(subquery) with true argument too
and to tmp_table_param->field array cleanup which is required later.
The problem is that Item_func_set_user_var does not set
result_filed which leads to unnecessary repeated excution of subquery
on final stage.
The fix is to set result_field for Item_func_set_user_var.

not address the printouts issue

Detailed revision comments:

r6310 | marko | 2009-12-15 15:23:54 +0200 (Tue, 15 Dec 2009) | 30 lines
branches/5.1: Merge r4922 from branches/zip.

This the fix for the first part of Bug #41609 from InnoDB Plugin to
the built-in InnoDB in MySQL 5.1. This allows InnoDB Hot Backup to
back up a database while the built-in InnoDB in MySQL 5.1 is creating
temporary tables. (This fix does not address the printouts about
missing .ibd files for temporary tables at InnoDB startup, which was
committed to branches/zip in r6252.)

rb://219 approved by Sunny Bains.

branches/zip: Distinguish temporary tables in MLOG_FILE_CREATE.
This addresses Mantis Issue #23 in InnoDB Hot Backup and some
of MySQL Bug #41609.

In MLOG_FILE_CREATE, we need to distinguish temporary tables, so that
InnoDB Hot Backup can work correctly.  It turns out that we can do this
easily, by using a bit of the previously unused parameter for page number.
(The page number parameter of MLOG_FILE_CREATE has been written as 0 
ever since MySQL 4.1, which introduced MLOG_FILE_CREATE.)

MLOG_FILE_FLAG_TEMP: A flag for indicating a temporary table in
the page number parameter of MLOG_FILE_ operations.

fil_op_write_log(): Add the parameter log_flags.

fil_op_log_parse_or_replay(): Add the parameter log_flags.
Do not replay MLOG_FILE_CREATE when MLOG_FILE_FLAG_TEMP is set in log_flags.
This only affects ibbackup --apply-log.  InnoDB itself never replays file
operations.

Detailed revision comments:

r6306 | calvin | 2009-12-14 15:12:46 +0200 (Mon, 14 Dec 2009) | 5 lines
branches/5.1: fix bug#49267: innodb-autoinc.test fails on windows
because of different case mode

There is no change to the InnoDB code, only to fix test case by
changing "T1" to "t1".

When the $diff_statement variable for diff_master_slave.inc was
put in multiple lines, the rear part of the statement would be 
missing when being executed on Windows systems.

Fixed the problem by always putting the value for $diff_statement
in one line.

unnecessarily

Changing an instance of the define that was missed
in the original commit due to the fact that it was
misspelled.

Post-merge fix: wait for statement result before disconnecting.
Otherwise, the statement might affect unrelated tests.

MySQL 5.1 specific fixes.

Bug#35589 SET PASSWORD caused a crash
Bug#35591 FLUSH PRIVILEGES caused a crash
      
A race condition on the privilege hash tables (proc_priv_hash
and func_priv_hash) caused one thread to try to delete elements
that had already been deleted by another thread.
      
The bug was caused by reading and saving the pointers to 
the hash tables outside mutex protection.  This led to an
inconsistency where a thread copied a pointer to a hash,
another thread did the same, the first thread then deleted
the hash, and the second then crashed when it in turn tried to
delete the deleted hash.
      
The fix is to ensure that operations on the shared hash structures
happens under mutex protection (moving the locking up a little)

The problem is a somewhat common misusage of the strmake function.
The strmake(dst, src, len) function writes at most /len/ bytes to
the string pointed to by src, not including the trailing null byte.
Hence, if /len/ is the exact length of the destination buffer, a
one byte buffer overflow can occur if the length of the source
string is equal to or greater than /len/.

The test allowed random coincidence of connection ids for two concurrent
sessions performing CREATE/DROP temp tables.

Fixed with correcting the test. The sessions connection ids are not changed
from their defaults anymore.

                  
When compressed myisam files are opened, they are always memory mapped
sometimes causing memory swapping problems.

When we mmap the myisam compressed tables of size greater than the memory 
available, the kswapd0 process utilization is very high consuming 30-40% of 
the cpu. This happens only with linux kernels older than 2.6.9

With newer linux kernels, we don't have this problem of high cpu consumption
and this option may not be required.
 
The option 'myisam_mmap_size' is added to limit the amount of memory used for
memory mapping of myisam files. This option is not dynamic.

The default value on 32 bit system is 4294967295 bytes and on 64 bit system it
is 18446744073709547520 bytes.

Note: Testcase only tests the option variable. The actual bug has be to 
tested manually.

returns incorrect results with where

An outer join of a const table (outer) and a normal table
(inner) with GROUP BY on a field from the outer table would
optimize away GROUP BY, and thus trigger the optimization to
do away with a temporary table if grouping was performed on
columns from the const table, hence executing the query with
filesort without temporary table. But this should not be
done if there is a non-indexed access to the inner table,
since filesort does not handle joins. It expects either ref
access, range ditto or table scan. The join condition will
thus not be applied.

Fixed by always forcing execution with temporary table in
the case of ROLLUP with a query involving an outer join. This
is a slightly broader class of queries than need fixing, but
it is hard to ascertain the position of a ROLLUP field wrt
outer join with current query representation.

Problem: inserting a record we don't set unused null bits in the
record buffer if no default field values used.
That may lead to wrong live checksum calculation.

Fix: set unused null bits in the record buffer in such cases.

The bug is caused by a race condition between the 
INSERT DELAYED thread and the client thread's FLUSH TABLE.  The 
FLUSH TABLE does not guarantee (as is (wrongly) suggested in the 
test case) that the INSERT DELAYED is ever executed.  The 
execution of the test case will thus not be deterministic.

The fix has been to do a deterministic verification that both
threads are complete by checking the content of the table.

Calling push_warning/push_warning_printf with a level of
WARN_LEVEL_ERROR *is* a bug. We should either use my_error(),
or WARN_LEVEL_WARN.

This test case tests a circular replication of four hosts. 
A--->B--->C--->D--->A
The replicate is slow and needs more time to replicate all data in the circle.
The time it spends to replicate, sometimes, is longer than the time that 
wait_condition.inc spends to wait that all data has been replicated. This
cause sporadical failure of this test case.
  
This patch uses sync_slave_with_master to ensure that all data can be replicated
successfully in the circle.

Only relative log events are showed.

 int join_read_key(JOIN_TAB*)

The eq_ref access method TABLE_REF (accessed through 
JOIN_TAB) to save state and to track if this is the 
first row it finds or not.
This state was not reset on subquery re-execution
causing an assert.

Fixed by resetting the state before the subquery 
re-execution.

 int join_read_key(JOIN_TAB*)

The eq_ref access method TABLE_REF (accessed through 
JOIN_TAB) to save state and to track if this is the 
first row it finds or not.
This state was not reset on subquery re-execution
causing an assert.

Fixed by resetting the state before the subquery 
re-execution.

Problem: add_collation did not check that cs->number is smaller
than the number of elements in the array all_charsets[],
so server could crash when loading an Index.xml file with
a collation ID greater the number of elements 
(for example when downgrading from 5.5).

Fix: adding a condition to check that cs->number is not out of valid range.

check_key_in_view() had one code branch which returned with "return TRUE"
rather than "DBUG_RETURN(TRUE)". Only affected debug builds.

No test case added.