The function setup_tables should handle table_list elements for
semijoin materialized tables in a special way when executing
a prepared statement for the second time.

The function simple_pred did not take into account that a multiple equality
could include ref items (more exactly items of the class Item_direct_view_ref).
It caused crashes for queries over derived tables or views if the
min/max optimization could be applied to these queries.

- evaluate_null_complemented_join_record() should perform FirstMatch checks.

- Do make the DuplicateWeedout check for outer joins.

- Testcase.

The patch for bugs 717577 and 724942 has missed to make adjustments for the
call item_equal->add_const(const_item, orig_field_item) in the function
check_simple_equality that builds multiple equality for a field and a constant.
As a result, when this field happens to be a view field and the corresponding
Item_field object F is wrapped in an Item_direct_view_ref object R the object
F is placed in the multiple equality instead of the object R.
A substitution of an equal item for F potentially can cause very serious
problems and in some cases can lead to crashes of the server.

- Make make_outerjoin_info() correctly process semi-join nests
- Make make_join_select() attach conditions to the right places.

Removed forgotten EXPLAIN EXTENDED from the test file.

Automerged with 5.3.

- Added regression test with queries over the WORLD database.
- Discovered and fixed several bugs in the related cost calculation
  functionality both in the semijoin and non-semijon subquery code.
- Added DBUG printing of the cost variables used to decide between
  IN-EXISTS and MATERIALIZATION.

-In  do_sj_dups_weedout(), set nulls_ptr to point to NULL bytes (and not to length bytes) of the DuplicateWeedout column.

- Testcase

BUG#761598: InnoDB: Error: row_search_for_mysql() is called without ha_innobase::external_lock() in maria-5.3
- Testcase

- Add testcase

The previous patch partially fixed things by waiting for the old dump thread
on the master to exit before injecting the DBUG error. This prevents the error
injection going to the wrong thread.

However, there is still the problem that the old dump thread may never exit,
causing the wait to time out. This happens if the dump thread manages to write
all events down the socket before the socket is closed by the slave. The
master dump thread only checks for slave gone when writing a new event, so if
no new events are generated, old dump threads can hang around forever on the
master after the slave disconnects.

Fix by explicitly killing the old dump thread if it is still around.

(Changeset sp1r-igor@olga.mysql.com-20070526173301-38848 moved this loop from one place 
to another, then the merge of sp1r-gshchepa/uchum@gleb.loc-20070527192244-26330  have 
kept both copies).

- move attempt to evaluate join->exec_const_cond() out of the "Extract constant part of each ON expression" loop
  (it got there by mistake when merging).

mysql-test/suite/maria/t/maria3.test:
  Fix when compiling with safemalloc
storage/maria/ha_maria.cc:
  Fix that MAX_FILE_SIZE is not limited on 32 bit machines.

- Add a testcase (the bug has already been fixed)

- Handle the case when the subquery's join is degenerate and so has zero tables.

from an ad hoc set of limitations
to a correct rule

Fixed reference to not initialized memory detected by valgrind

sql/sql_select.cc:
  A bit better fix for tmp-table problem:
  Use only dynamic_record format for group by and distinct.
storage/maria/ma_create.c:
  DYNAMIC_RECORD format doesn't pack VARCHAR fields.
  This change fixes a non-fatal uninitialized memory copy.

The function generate_derived_keys did not take into account the fact
that the last element in the array of keyuses could be just a barrier
element. In some cases it could lead to a crash of the server.

Also fixed a couple of other bugs in generate_derived_keys: the inner 
loop in the body of if this function did not change the cycle variables
properly.

The reason for this is that BLOCK_RECORD format is not good when there is a lot of duplicated keys as it first writes the data (to get the row position) and
then writes the key (and thus checks for duplicates).