The problem was that connection con5, which is supposed to be the leader for
the third group, could if timing was bad end up as participant in the second
group, causing the test to fail.

Fixed by ensuring that group 2 is running before starting the transaction
for group 3.

- In eliminate_item_equal(), we could end up in a situation where:
  = The multiple equality has a constant C1 (and so it is the "head item")
  = The join order was such that we've generated "sj_inner_table1=C1" equality,
    and now are looking to generate "sj_inner_table2_=..." equality. 
  When looking for what should be the other member of equality, we run

      Item *head_item= current_sjm? current_sjm_head: head;
  
  which sees current_sjm!=NULL, and takes current_sjm_head (which is NULL because 
  the constant C1 is the head for all cases).

- Fixed in a trivial way: take current_sjm_head if we don't have constant.

- Handle the case of degenerate joins. When join has impossible WHERE clause,
  a number of its members, including JOIN::map2table, are not initialized. 
  Do not try accessing them, detect degenerate joins early.

- Fix trivial bugs in post-GROUP-BY output cardinality calculations
- Add testcases

check for outer joins (and not for any "t1 SOME_JOIN t2 ON cond" syntax).

- Take into account that grouping or aggregates decrease join output cardinality.
  (First code, can't make use of index statistics yet)

MWL#180: Merge bugfix from 5.2 to 5.3 codebase + really fix version from which mariadb supports binlog checksums.

Analysis:
The method st_select_lex::optimize_unflattened_subqueries()
incorrectly propagated to each subquery the complete
select_options flag set for the whole query. Among other
flags in select_options, this propagated incorrectly the
STRAIGHT_JOIN flag from the upper query to the subquery.

Solution:
During EXPLAIN set only the SELECT_DESCRIBE bit in the
select_options of the subquery.

If the value of the flag cond_false of an Item_equal object is
true then the print method must return the string '0'.

Adjusted test results after merge.

Merge with main 5.3

The third parameter in the call of make_cond_for_table() that
built the pushed condition containing only outer references
was incorrect. This condition appeared for the first time in
the patch fixing bug 729039.
  

MWL#180: merge fixes from 5.2-rpl + forgot to adjust revision from which checksums are supported when merging into 5.3-based tree.

 - Fix windows CMake build.
 - Merge some later test case fixes, to see if they solve the random rpl_checksum failure.

Pushing test case only. The bug itself was fixed by the
combined patches for LP BUG#717577 and LP BUG#776274.

The bug was introduced by the patch that fixed bug 717577.

Patch backported:

bzr diff
'-rrevid:alfranio.correia@oracle.com-20101121143257-se3vpqus73l4mum0
..revid:luis.soares@oracle.com-20101124111752-9b8260bd1qak87hr'
--old=lp:mysql-server --new=lp:mysql-server

Merge with 5.3

presumably neither TMP nor TEMP environment variable are set.

mysql-test/suite/funcs_1/r/storedproc.result:
  Fixed test failure
mysql-test/suite/funcs_1/t/storedproc.test:
  Fixed test failure
  (The error changed as syntax for alter changed with ALTER ONLINE)
storage/maria/ha_maria.cc:
  fixed compiler warning

- Debug build: make DBUG_ASSERT statements really look at the first table

One can't expect cursors to work with semi-join subqueries anyway, 
though (which isn't a problem because cursors are not used anywhere)

Added ALTER ONLINE TABLE, which will give an error if the change can't be done 'instantly' (without a table copy)


mysql-test/r/alter_table_online.result:
  Test new feature
mysql-test/t/alter_table_online.test:
  Test new feature
sql/handler.cc:
  Added comment
sql/lex.h:
  Added ONLINE keyword
sql/mysql_priv.h:
  Added option to alter table to require online operation
sql/share/errmsg.txt:
  Added error message if ONLINE can't be done
sql/sql_lex.h:
  Added online option
sql/sql_parse.cc:
  Added online option to mysql_alter_table()
sql/sql_table.cc:
  Added test that gives error if table can't be done instantly when requsted to be online.
  Fixed wrong test if table includes a VARCHAR
  Fixed wrong (but unlikely) handling of error conditions in ALTER table
sql/sql_yacc.yy:
  Added ALTER ONLINE TABLE syntax
storage/maria/ha_maria.cc:
  Fixed bug where 'start_bulk_insert' used too small buffer if used with unknown number of rows

This makes it possible to do safe multi volume snapshots as long as one snapshots the volume with the transaction logs last.


include/mysql_com.h:
  Added REFRESH_CHECKPOINT
mysql-test/r/flush.result:
  Added test of new FLUSH TABLES syntax + calls to checkpoint_status handler calls
mysql-test/t/flush.test:
  Added test of new FLUSH TABLES syntax + calls to checkpoint_status handler calls
sql/handler.cc:
  Added code to call checkpoint_state for all handlertons that supports it
sql/handler.h:
  Added new checkpoint_state() handlerton call to temporarly disable checkpoints.
sql/lex.h:
  Added CHECKPOINT keyword
sql/sql_yacc.yy:
  Added support for FLUSH TABLES WITH READ LOCK AND DISABLE CHECKPOINT
storage/maria/ha_maria.cc:
  Added handlerton call to disable checkpoints.
storage/maria/ma_checkpoint.c:
  Don't do checkpoint if checkpoints are disabled.
storage/maria/ma_static.c:
  Added maria_checkpoint_disabled
storage/maria/maria_def.h:
  Added maria_checkpoint_disabled
storage/xtradb/handler/ha_innodb.cc:
  Added handlerton call to disable checkpoints.
storage/xtradb/include/log0log.h:
  Added option to log_checkpoint() to allow one to ignore not critical checkpoints during the time checkpoints are disabled.
storage/xtradb/log/log0log.c:
  Added code to allow one to disable checkpoints during a FLUSH TABLES ... DISABLE CHECKPOINT
  This was done by adding a new argument to log_checkpoint() which tells us when the checkpoint is called by srv_master_thread (which are safe to ignore)
storage/xtradb/srv/srv0srv.c:
  Tell log_checkpoint() that checkpoints from srv_master_thread() are safe to ignore (will just delay recovery time a bit).

Analysis:
Build_equal_items_for_cond() rewrites the WHERE clause in such a way,
that it may merge the list join->cond_equal->current_level with the
list of child Items in an AND condition of the WHERE clause.

The place where this is done is:
static COND *build_equal_items_for_cond(THD *thd, COND *cond,
                                        COND_EQUAL *inherited)
{
  ...
      if (and_level)
    {
      args->concat(&eq_list);
      args->concat((List<Item> *)&cond_equal.current_level);
    }
  ...
}

As a result, later transformations on the WHERE clause may change the
structure of the list join->cond_equal->current_level without knowing this.

Specifically in this bug, Item_in_subselect::inject_in_to_exists_cond
creates a new AND of the old WHERE clause and the IN->EXISTS conditions.
It then calls fix_fields() for the new AND. Among other things, fix_fields
flattens all nested ANDs into one by merging the AND argument lists.

When there is a cond_equal for the JOIN, its list of Item_equal objects
is attached to the end of the original AND. When a lower-level AND is
merged into the top-level one, the argument list of the lower-level AND
is concatenated to the list of multiple equalities in the upper-level AND.

As a result, when substitute_for_best_equal_field processes the 
multiple equalities, it turns out that the multiple equality list contains
the Items from the lower-level AND which were concatenated to the end of
the join->cond_equal->current_level list. This results in a crash because
this list must not contain any other Items except for the previously found
Item_equal ones.

Solution:
When performing IN->EXIST predicate injection, and the where clause is an
AND, detach the list of Item_equal objects before calling fix_fields on
the injected where clause.

After fix_fields is done, reattach back the multiple equalities list to
the end of the argument list of the new AND.

The function test_quick_select by mistake did not update the value
of table->quick_condition_rows for index intersection scans though
the specification explicitly required to do so from any table access
plan once the plan provided a better upper bound for the number of
rows selected from the table. It resulted in a bogus, usually very
big number saved as the cost of the table access. This, in its turn,
in many cases forced the optimizer to make a bad choice of the
execution plan for join queries.