When using Unique Keys with nullable parts in RBR, the slave can
choose the wrong row to update. This happens because a table with
an unique key containing nullable parts cannot strictly guarantee 
uniqueness. As stated in the manual, for all engines, a UNIQUE 
index allows multiple NULL values for columns that can contain 
NULL.

We fix this at the slave by extending the checks before assuming
that the row found through an unique index is is the correct
one. This means that when a record (R) is fetched from the storage
engine and a key that is not primary (K) is used, the server does 
the following: 

 - If K is unique and has no nullable parts, it returns R;
 - Otherwise, if any field in the before image that is part of K
   is null do an index scan;
 - If there is no NULL field in the BI part of K, then return R.

A side change: renamed the existing test case file and added a
test case covering the changes in this patch.

MTR will ignore fully qualified test name entries in disabled.def 
lists. Therefore, it would still run the test case, even if it is
listed.

This patch fix this by extending the check when marking the test
case as disabled to take into consideration not only the cases that
contain the simple test name but also those that contain fully 
qualified test names.

result file differs on embedded

Field_time::get_date method does not initialize MYSQL_TIME::time_type field.
The fix is to init this field.


mysql-test/r/type_time.result:
  test case
mysql-test/t/type_time.test:
  test case
sql/field.cc:
  --use Field_time::get_time in Field_time::get_date
  --removed duplicated code in Field_time::get_date method

            and .tar.gz, windows vs linux..

On Intel x86 machines index selection by the MySQL query
optimizer could sometimes depend on the compiler version and
optimization flags used to build the server binary.

The problem was a result of a known issue with floating point
calculations on x86: since internal FPU precision (80 bit)
differs from precision used by programs (32-bit float or 64-bit
double), the result of calculating a complex expression may
depend on how FPU registers are allocated by the compiler and
whether intermediate values are spilled from FPU to memory. In
this particular case compiler versions and optimization flags
had an effect on cost calculation when choosing the best index
in best_access_path().

A possible solution to this problem which has already been
implemented in mysql-trunk is to limit FPU internal precision
to 64 bits. So the fix is a backport of the relevant code to
5.1 from mysql-trunk.

configure.in:
  Configure check for fpu_control.h
mysql-test/r/explain.result:
  Test case for bug #48537.
mysql-test/t/explain.test:
  Test case for bug #48537.
sql/mysqld.cc:
  Backport of the code to switch FPU on x86 to 64-bit precision.

err_index could be not a member of the share structure or prebuilt
structure passed from MySQL. For now, we resort to the traditional
way of scanning index->table for the index number.

Add code to waiting for a set of errors.
Add code to waiting for an error instead of waiting for io thread to stop, as
after 'START SLAVE', the status of io thread is still not running.
But it doesn't mean slave io thread encounters an error.

without FOR UPDATE is causing a lock".

SELECT statements with subqueries referencing InnoDB tables
were acquiring shared locks on rows in these tables when they
were executed in REPEATABLE-READ mode and with statement or
mixed mode binary logging turned on.

This was a regression which were introduced when fixing
bug 39843.

The problem was that for tables belonging to subqueries
parser set TL_READ_DEFAULT as a lock type. In cases when
statement/mixed binary logging at open_tables() time this
type of lock was converted to TL_READ_NO_INSERT lock at
open_tables() time and caused InnoDB engine to acquire
shared locks on reads from these tables. Although in some
cases such behavior was correct (e.g. for subqueries in
DELETE) in case of SELECT it has caused unnecessary locking.

This patch implements minimal version of the fix for the
specific problem described in the bug-report which supposed
to be not too risky for pushing into 5.1 tree.
The 5.5 tree already contains a more appropriate solution
which also addresses other related issues like bug 53921
"Wrong locks for SELECTs used stored functions may lead
to broken SBR".

This patch tries to solve the problem by ensuring that
TL_READ_DEFAULT lock which is set in the parser for
tables participating in subqueries at open_tables()
time is interpreted as TL_READ_NO_INSERT or TL_READ.
TL_READ is used only if we know that this is a SELECT
and that this particular table is not used by a stored
function.

Test coverage is added for both InnoDB and MyISAM.

This patch introduces an "incompatible" change in locking
scheme for subqueries used in SELECT ... FOR UPDATE and
SELECT .. IN SHARE MODE.

In 4.1 (as well as in 5.0 and 5.1 before fix for bug 39843)
the server would use a snapshot InnoDB read for subqueries
in SELECT FOR UPDATE and SELECT .. IN SHARE MODE statements,
regardless of whether the binary log is on or off.

If the user required a different type of read (i.e. locking
read), he/she could request so explicitly by providing FOR
UPDATE/IN SHARE MODE clause for each individual subquery.

The patch for bug 39843 broke this behaviour (which was not
documented or tested), and started to use locking reads for
all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE.
This patch restores 4.1 behaviour.

This patch should be mostly null-merged into 5.5 tree.

mysql-test/include/check_concurrent_insert.inc:
  Added auxiliary script which allows to check if statement
  reading table allows concurrent inserts in it.
mysql-test/include/check_no_concurrent_insert.inc:
  Added auxiliary script which allows to check that statement
  reading table doesn't allow concurrent inserts in it.
mysql-test/include/check_no_row_lock.inc:
  Added auxiliary script which allows to check if statement
  reading table doesn't take locks on its rows.
mysql-test/include/check_shared_row_lock.inc:
  Added auxiliary script which allows to check if statement
  reading table takes shared locks on some of its rows.
mysql-test/r/bug39022.result:
  After bug #46947 'Embedded SELECT without FOR UPDATE is
  causing a lock' was fixed test case for bug 39022 has to
  be adjusted in order to trigger execution path on which
  original problem was encountered.
mysql-test/r/innodb_mysql_lock2.result:
  Added coverage for handling of locking in various cases when
  we read data from InnoDB tables (includes test case for
  bug #46947 'Embedded SELECT without FOR UPDATE is causing a
  lock').
mysql-test/r/lock_sync.result:
  Added coverage for handling of locking in various cases when
  we read data from MyISAM tables.
mysql-test/t/bug39022.test:
  After bug #46947 'Embedded SELECT without FOR UPDATE is
  causing a lock' was fixed test case for bug 39022 has to
  be adjusted in order to trigger execution path on which
  original problem was encountered.
mysql-test/t/innodb_mysql_lock2.test:
  Added coverage for handling of locking in various cases when
  we read data from InnoDB tables (includes test case for
  bug #46947 'Embedded SELECT without FOR UPDATE is causing a
  lock').
mysql-test/t/lock_sync.test:
  Added coverage for handling of locking in various cases when
  we read data from MyISAM tables.
sql/mysql_priv.h:
  Function read_lock_type_for_table() now takes pointers to
  LEX and TABLE_LIST elements as its arguments since to
  correctly determine lock type it needs to know what
  statement is being performed and whether table element for
  which lock type to be determined belongs to prelocking list.
sql/sql_base.cc:
  Changed read_lock_type_for_table() to return a weak TL_READ
  type of lock in cases when we are executing SELECT (and so
  won't update tables directly) and table doesn't belong to
  statement's prelocking list and thus can't be used by a
  stored function. It is OK to do so since in this case table
  won't be used by statement or function call which will be
  written to the binary log, so serializability requirements
  for it can be relaxed.
  One of results from this change is that SELECTs on InnoDB
  tables no longer takes shared row locks for tables which
  are used in subqueries (i.e. bug #46947 is fixed).
  Another result is that for similar SELECTs on MyISAM tables
  concurrent inserts are allowed.
  In order to implement this change signature of
  read_lock_type_for_table() function was changed to
  take pointers to LEX and TABLE_LIST objects.
sql/sql_update.cc:
  Function read_lock_type_for_table() now takes pointers to
  LEX and TABLE_LIST elements as its arguments since to
  correctly determine lock type it needs to know what
  statement is being performed and whether table element for
  which lock type to be determined belongs to prelocking list.

list a thread doing a wait_ex as an s-lock waiter.

There are two problems:
1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint
is used for whole SELECT we do not count it and as result some dependendecies
might be lost. It leads to incorrect table order which is returned by
join_tab_cmp_straight() function.
2. make_join_statistics() calculate the transitive closure for relations a particular
JOIN_TAB is 'dependent on'.
We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other
tables which we depend on. However, this may also cause new dependencies to be
available after we have completed processing a certain JOIN_TAB.
Both these problems affect condition pushdown and as result condition might be pushed
into wrong table which leads to crash or even omitted which leads to wrong result.
The fix:
1. Use modified 'transitive closure' algorithm provided by Ole John Aske
2. Update table dependences in simplify_joins according to 
   global STRAIGHT_JOIN hint.
Note: the patch also fixes bugs 46091 & 51492


mysql-test/r/join_outer.result:
  test case
mysql-test/t/join_outer.test:
  test case
sql/sql_select.cc:
  1. Use modified 'transitive closure' algorithm provided by Ole John Aske
  2. Update table dependences in simplify_joins according to 
     global STRAIGHT_JOIN hint.

Removed misleading comments.

after fast alter table added unique key". Look up MySQL index number should
go through index translation table.

rb://347, approved by Marko

             bitmap_is_set(table->read_set, field_index))

UPDATE on an InnoDB table modifying the same index that is used
to satisfy the WHERE condition could trigger a debug assertion
under some circumstances.

Since for engines with the HA_PRIMARY_KEY_IN_READ_INDEX flag
set results of an index scan on a secondary index are appended
by the primary key value, if a query involves only columns from
the primary key and a secondary index, the latter is considered
to be covering.

That tricks mysql_update() to mark for reading only columns
from the secondary index when it does an index scan to retrieve
rows to update in case a part of that key is also being
updated. However, there may be other columns in WHERE that are
part of the primary key, but not the secondary one.

What we actually want to do in this case is to add index
columns to the existing WHERE columns bitmap rather than
replace it.

mysql-test/r/innodb_mysql.result:
  Test case for bug #53830.
mysql-test/t/innodb_mysql.test:
  Test case for bug #53830.
sql/sql_update.cc:
  Add index columns to the read_set bitmap, don't replace it.
sql/table.cc:
  Added a new add_read_columns_used_by_index() function to 
  st_table.
sql/table.h:
  Added a new add_read_columns_used_by_index() function to 
  st_table.

Problem: one with SELECT privilege on some table may dump other table
performing COM_TABLE_DUMP command due to missed check of the table name.

Fix: check the table name.


sql/sql_parse.cc:
  Fix for bug #53907: Table dump command can be abused to dump arbitrary tables.
    - check given table name performing COM_TABLE_DUMP command.
tests/mysql_client_test.c:
  Fix for bug #53907: Table dump command can be abused to dump arbitrary tables.
    - test case.

Problem was reporting wrong error

Fixed by adding a new error which better explain the problem.

mysql-test/r/partition_error.result:
  Bug#49161: Out of memory; restart server and try again (needed 2 bytes)
  
  Updated test result
mysql-test/t/partition_error.test:
  Bug#49161: Out of memory; restart server and try again (needed 2 bytes)
  
  Added test case
sql/ha_partition.cc:
  Bug#49161: Out of memory; restart server and try again (needed 2 bytes)
  
  Better error message. (used ER_UNKNOWN_ERROR to avoid merge
  problems in mysql-trunk+)

This fixes a recently introduced regression, where a variable is
not defined for the embedded server. Although the embedded server
is not supported in 5.0, make it at least compile.

OpenBSD releases.

Apply patch from Brad Smith, thanks!

accessing uninitialized memory in Valgrind-instrumented builds.

(this changeset does not introduce any changes)

This is a port of
vasil.dimov@oracle.com-20100521175337-c1b1lqxgizqegb0w and
vasil.dimov@oracle.com-20100521180951-mef23h24k023xuwq
from mysql-trunk-innodb