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.

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.

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

Removed misleading comments.

             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.

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.

Problem was reporting wrong error

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

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!

Some of the test cases reference to binlog position and
these position numbers are written into result explicitly.
It is difficult to maintain if log event format changes. 

There are a couple of cases explicit position number appears, 
we handle them in different ways
A. 'CHANGE MASTER ...' with MASTER_LOG_POS or/and RELAY_LOG_POS options
   Use --replace_result to mask them.
B. 'SHOW BINLOG EVENT ...'
   Replaced by show_binlog_events.inc or wait_for_binlog_event.inc. 
   show_binlog_events.inc file's function is enhanced by given
   $binlog_file and $binlog_limit.
C. 'SHOW SLAVE STATUS', 'show_slave_status.inc' and 'show_slave_status2.inc'
   For the test cases just care a few items in the result of 'SHOW SLAVE STATUS',
   only the items related to each test case are showed.
   'show_slave_status.inc' is rebuild, only the given items in $status_items
   will be showed.
   'check_slave_is_running.inc' and 'check_slave_no_error.inc'
   and 'check_slave_param.inc' are auxiliary files helping
   to show running status and error information easily.

            data directory name command

The check_db_name function has been modified to validate tails of
#mysql50#-prefixed database names for compliance with MySQL 5.0
database name encoding rules (the check_table_name function call
has been reused).

Problem: The test case mysqldump reads a file that must
be world-readable. The test did not force the file to be
world-readable, so if the tree was branched with a umask
of 0077, the test would fail.
Fix: chmod the file.

Server crashes on 64bit linux with 'double free or corruption'
message, on 32bit mysql-test-run silently fails on bootstrap
stage. The problem is that FreeState() is called twice
for init_settings struct in _db_end_ function.
The fix is to remove superfluous FreeState() call.
Additional fix:
fixed discrepancy of result file when
debug & valgrind options are enabled
for MTR.

Bug #50087 Interval arithmetic for Event_queue_element is not portable.

Subtraction of two unsigned months yielded a (very large) positive value.
Conversion of this to a signed value was not necessarily well defined.
              
Solution: do the subtraction on signed values.

Analysis showed that in case of accessing I_S table
ROUTINES we perform unnecessary allocations
with get_field() function for every processed row that
in their turn causes significant memory growth.
the fix is to avoid use of get_field().

mode
      
Post-push fix after backporting the patch to 5.1-bugteam:

  1 - changed the name of some variables to be equivalent to pe.
  2 - fixed that patch to mark a statement as unsafe when both a
  self-logging eng. and regular eng. are accessed and one of them
  is updated.

Post-fix: Updated a test case after the patch for BUG#50410,
because the patch makes ndb to run in the row format and as
such unsafe warning messages are not printed out.

            ha_myisam::index_first(uchar*)") at assert.c:81

Single-table DELETE crash/assertion similar to single-table
UPDATE bug 14272.

Same resolution as for the bug 14272:
Don't run index scan when we should use quick select.
This could cause failures because there are table handlers (like federated)
that support quick select scanning but do not support index scanning.

MTR sporadically reported that rpl_do_grant does not
clean up after itself.

We fix this by backporting BUG 50984 fix. This deploys
missing synchronization between master and slave.

Additionally, it also fixes the check_testcase for
rpl_tmp_table_and_DDL.

      NULL from outer join query
      
      Problem: optimising MIN/MAX() queries without GROUP BY clause
      by replacing the aggregate expression with a constant, we may set it
      to NULL disregarding the fact that there may be outer joins involved.
      
      Fix: don't replace MIN/MAX() with NULL if there're outer joins.
      
      Note: the fix itself is just
      - if (!count)
      + if (!count && !outer_tables)
          set to NULL
      
      The rest of the patch eliminates repeated code to improve speed
      and for easy maintenance of the code.

update statements
      
Only SELECT statements report any examined rows in the slow
log. Slow UPDATE, DELETE and INSERT statements report 0 rows
examined, unless the statement has a condition including a
SELECT substatement.
      
This patch adds counting of examined rows for the UPDATE and
DELETE statements. An INSERT ... VALUES statement will still 
not report any rows as examined.

Problem: The rpl_ndb did not set binlog_format explicitly. Since
the default is binlog_format=statement, it means that the suite
ran with that. ndb does not support binlog_format=statement,
and many tests were skipped because they sourced
include/have_binlog_format_row_or_mixed.inc
Fix: set binlog_format=row explicitly in the configuration file
for the rpl_ndb suite.

      
MySQL handles the join syntax "JOIN ... USING( field1,
... )" and natural joins by building the same parse tree as
a corresponding join with an "ON t1.field1 = t2.field1 ..."
expression would produce. This parse tree was not cleaned up
properly in the following scenario. If a thread tries to
lock some tables and finds that the tables were dropped and
re-created while waiting for the lock, it cleans up column
references in the statement by means a per-statement free
list. But if the statement was part of a stored procedure,
column references on the stored procedure's free list
weren't cleaned up and thus contained pointers to freed
objects.
      
Fixed by adding a call to clean up the current prepared
statement's free list.

This is a backport from MySQL 5.1