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.

Corrected PBXT test results (explains).

Analysis:
The wrong result is a consquence of sorting the subquery
result and then selecting only the first row due to the
artificial LIMIT 1 introduced by the fix_fields phase.
Normally, if there is an ORDER BY in a subquery, the ORDER
is removed (Item_in_subselect::select_in_like_transformer),
however if a GROUP BY is transformed into ORDER, this happens
later, after the removal of the ORDER clause of subqueries, so
we end up with a subquery with an ORDER clause, and an artificially
added LIMIT 1.

The reason why the same works in the main 5.3 without MWL#89, is
that the 5.3 performs all subquery transformations, including
IN->EXISTS before JOIN::optimize(). The beginning of JOIN::optimize
does:
  if (having || (select_options & OPTION_FOUND_ROWS))
    select_limit= HA_POS_ERROR;
which sets the limit back to infinity, thus 5.3 sorts the whole
subquery result, and IN performs the lookup into all subquery result
rows.

Solution:
Sorting of subqueries without LIMIT is meaningless. Since LIMIT in
subqueries is not supported, the patch removes sorting by setting
  join->skip_sort_order= true
for each subquery JOIN object. This improves a number of execution
plans to not perform unnecessary sorting at all.

There is no patch because the bug cannot be reproduced any more.

- Auto-merge with 5.3 main.
- Changed the test for LP BUG#719198 so that
  an two more queries were added, and removed a
  query that produces a wrong result due to an
  unrelated problem. The wrong result is submitted
  as a separate bug.

sql/key.cc:
  Fixed compiler warnings about not initialized variables

sql/item.cc:
  If a item_ref is referenced by name, we have to reset it's ref in item_ref::cleanup() as the reference may be to a memory that is freed.
  This happens at least when you have 'HAVING MAX()' in a sub query and you execute 'cond_having->print()' which tries to access items before fix fields.
sql/item.h:
  Added 'reference_trough_name' as a marker for Item_ref that needs to have ref reset during cleanup

Fixed memory leak from HEAP tables that was not deleted properly


BUILD/compile-alpha-ccc:
  Use g++ instead of gcc for linking
BUILD/compile-alpha-debug:
  Use g++ instead of gcc for linking
BUILD/compile-pentium-pgcc:
  Use g++ instead of gcc for linking
BUILD/compile-solaris-sparc:
  Use g++ instead of gcc for linking
BUILD/compile-solaris-sparc-debug:
  Use g++ instead of gcc for linking
BUILD/compile-solaris-sparc-purify:
  Use g++ instead of gcc for linking
sql/item.cc:
  Safety fixes for expr_cache
  Call Item_result:field::cleanup() in Item_cache_wrapper::cleanup()
  More DBUG_PRINT
sql/sql_base.cc:
  Simple optimization for setup_wild
  More DBUG_PRINT
sql/sql_expression_cache.cc:
  Added header
  Removed not needed initialization
sql/sql_lex.cc:
  More DBUG_PRINT
sql/sql_select.cc:
  More DBUG_PRINT
  Fixed memory leak from HEAP tables that was not deleted properly
storage/heap/hp_create.c:
  More DBUG_PRINT

All failing cases were attempts to use connection after
the server was brought down and restarted. Connections 
used client reconnect option.

The reason for failures is the behavior of sockets on Windows:
for a short period after crash (short enough to make the error 
not reproducible under debugger), write to socket on client
side would succeed but subsequent read would fail. 

MYSQL_OPT_RECONNECT does not really help in this case ,
because  in the case given here ,as  mysql_real_query() 
(which can handle reconnect option)  succeeds and 
mysql_read_results() (can't handle reconnect) fails.

The fix is adding --include wait_until_connected_again.inc to 
appropriate places in test. This ensures that read errors are 
caught and connection is recreated.

Fixed problem that fill_record() allocated memory for every call. This could be a problem when doing big unions as memory could be filled up.

sql/sql_base.cc:
  Don't allocate memory in fill_record().
  Fix was to remove the list of tables. This was not necessary as this call is only used with one table.

mysql-test/mysql-test-run.pl:
  Set port-open-timeout to 10 to retry binds
sql/mysqld.cc:
  Write error number for bind failure. (perror can't do that on windows as errno dosn't contain error code)

  
  Merge 5.3 with 5.3-mwl89.

Merge 5.3 with 5.3-mwl89.

Parameter setting has the effect on 4th part of the version string in executable's version info on Windows.
It could be set e.g to bzr revno to uniquely identify  different builds for the same major.minor.patch combo.

Use MYSQL_INSTALL_TARGETS() macro for DLLs 
(libmysql and libmysqld) to ensure that libraries
are signed, if signing is requested.

add a read-only server variable @@myisam_block_size

Remove SIGNCODE_ENABLED variable from create_msi.cmake.in,
it was already removed from other places.

Analysis:
There are two code paths through which JOIN::exec may produce
an all-NULL row for an empty result set. One goes via the
function return_zero_rows(), when query processing detectes
early that the where clause is false, the other one is via
do_select() in the case of join execution.

In the case of do_select(), the problem was that the executioner
didn't set TABLE::null_row to 1. As result when sending the only
result row, the evaluation of each field didn't detect that all
non-aggregated fields are NULL, because Field::is_null returned
true, after checking that field->table->null_row was false.

Given that the each non-aggregated field was not considered NULL,
select_result::send_data sent whatever was in the buffer of each
field. However, since there was no actual data in the field buffer,
send_data() accessed and sent whatever junk was in the field's
data buffer.

Solution:
Similar to the analogous case in return_zero_rows() mark all
tables that their current row is NULL before sending the
artificailly created NULL row.

mysql-test/mysql-test-run.pl:
  Don't set --log-error when running embedded server as we don't want the mysqltest output into mysqld.1.err
sql/mysqld.cc:
  Allow one to disable --log-error

- FIND_PROGRAM (signtool) will now get a hint about location of signtool.exe (Windows SDK)
- Targets "package" or "msi" will now fail, l if signing is requested but does not work
  (e.g invalid certificate)
- During install, do not re-sign binaries, if they are already signed.
- Preserve mysqld_error.h timestamp whenever possible. This helps avoiding situations 
where the whole server is rebuilt, whenever comp_err.exe changes (for example after code 
signing, or also after a minor fix in mysys)
- Fix Wix error in UpgradeVersion, if patch part of the version is 0.

- Address review feedback: introduce NO_REF_PART symbolic name, better comments

Analysis:
A query with implicit grouping is one with aggregate functions and
no GROUP BY clause. MariaDB inherits from MySQL an SQL extenstion
that allows mixing aggregate functions with non-aggregate fields.
If a query with such mixed select clause produces an empty result
set, the meaning of aggregate functions is well defined - either
NULL (MIN, MAX, etc.), or 0 (count(*)). However the non-aggregated
fields must also have some value, and the only reasonable value in
the case of empty result is NULL.

The cause of the many wrong results was that if a field is declared
as non-nullable (e.g. because it is a PK or NOT NULL), the semantic
analysis and the optimization phases treat this field as non-nullable,
and generate all related query plan elements based on this assumption.

Later during execution, these incorrectly configured/generated query
plan elements result in a wrong result because the selected fields
are not null due to the not-null assumption during optimization.

Solution:
Detect before the context analysys phase that a query uses implicit
grouping with mixed aggregates/non-aggregates, and set all fields
as nullable. The parser already walks the SELECT clause, and
already sets Item::with_sum_func for Items that reference aggreagate
functions. The patch adds a symmetric Item::with_field so that all
Items that reference an Item_field are marked during their
construction at parse time in the same way as with aggregate function
use.