In case of outer join and emtpy WHERE conditon
'always true' condition is created for WHERE clasue.
Later in mysql_select() original SELECT_LEX WHERE
condition is overwritten with created cond.
However SELECT_LEX condition is also used as inital
condition in mysql_select()->JOIN::prepare().
On second execution of PS modified SELECT_LEX condition
is taken and it leads to crash.
The fix is to restore original SELECT_LEX condition
(set to NULL if original cond is NULL) in
 reinit_stmt_before_use().
HAVING clause is fixed too for safety reason
(no test case as I did not manage to think out
 appropriate example).


mysql-test/r/ps.result:
  test case
mysql-test/t/ps.test:
  test case
sql/sql_prepare.cc:
  restore original SELECT_LEX condition
  (set to NULL if original cond is NULL) in
   reinit_stmt_before_use()

  
Disabled the test case.

Item_func_spatial_collection::fix_length_and_dec()
changed to use argument's print() method to print
the ER_ILLEGAL_VALUE_FOR_TYPE error.


mysql-test/r/gis.result:
  Fix for bug#56679: gis.test: valgrind error
    - test result adjusted.
sql/item_geofunc.h:
  Fix for bug#56679: gis.test: valgrind error
    - use argument's print() method instead of improper val_str()
  call in the Item_func_spatial_collection::fix_length_and_dec(), as
  it's applicable only for constant items.

were marked as experimental due to BUG38965.

bug 55568 because {1} isn't a valid geometry for a geometry
collection.

Convertion from a floating point number to a string caused a
crash.

During rare circumstances a String object could crash when
it was requested to allocate new memory.
A crash could occcur in Field_double::val_str() because of
a pointer referencing memory inside a String object which was
of unknown size.
And finally, the geometric collection should not accept
arguments which are non geometric.


mysql-test/r/gis.result:
  * Test cases change because we intercept the error behind the
  previous crashes much earlier.
sql/field.cc:
  * It makes no sense to impose a lower limit on the length
  and not setting a upper limit will cause crashes later.
sql/item_geofunc.h:
  * Disallow for binding with field- and item types which
  differ from MYSQL_TYPE_GEOMETRY types.

            called twice in a row

Queries with nested joins could cause an infinite loop in the
server when used from SP/PS.

When flattening nested joins, simplify_joins() tracks if the
name resolution list needs to be updated by setting
fix_name_res to TRUE if the current loop iteration has done any
transformations to the join table list. The problem was that
the flag was not reset before the next loop iteration leading
to unnecessary "fixing" of the name resolution list which in
turn could lead to a loop (i.e. circularly-linked part) in that
list. This was causing problems on subsequent execution when
used together with stored procedures or prepared statements.

Fixed by making sure fix_name_res is reset on every loop
iteration.

mysql-test/r/join.result:
  Added a test case for bug #53544.
mysql-test/t/join.test:
  Added a test case for bug #53544.
sql/sql_select.cc:
  Make sure fix_name_res is reset on every loop iteration.

bug #49251 (deadlock/crash with concurrent truncate table and index
statistics calculation) by backporting a solution from #54678 fixed
for 5.1 plugin and 5.5.

Make the my_compiler.h header, like my_attribute.h, part of
the distribution. This is required due to the dependency of
the former on the latter (which can undefine __attribute__).

            "Access compatibility" syntax

The "wild" "DELETE FROM table_name.* ... USING ..." syntax
for multi-table DELETE statements is documented but it was
lost in the fix for the bug 30234.

The table_ident_opt_wild parser rule has been added
to restore the lost syntax.


mysql-test/r/delete.result:
  Test case for bug #53034.
mysql-test/t/delete.test:
  Test case for bug #53034.
sql/sql_yacc.yy:
  Bug #53034: Multiple-table DELETE statements not accepting
              "Access compatibility" syntax
  
  The table_ident_opt_wild parser rule has been added
  to restore the lost syntax.
  Note: simple extending of table_ident with opt_wild in
  the table_alias_ref rule is not acceptable, because
  a) it adds one conflict more and b) this conflict resolves
  in the inappropriate way.

Check for number of line strings in the incoming polygon data (wkb) and
for number of points in the incoming linestring wkb.



mysql-test/r/gis.result:
  Fix for bug #51875: crash when loading data into geometry function polyfromwkb
    - test result.
mysql-test/t/gis.test:
  Fix for bug #51875: crash when loading data into geometry function polyfromwkb
    - test case.
sql/spatial.cc:
  Fix for bug #51875: crash when loading data into geometry function polyfromwkb
    - creating a polygon from wkb check for number of line strings,
    - creating a linestring from wkb check for number of line points.

            == MYSQL_TYPE_LONGLONG

A MIN/MAX() function with a subquery as its argument could lead
to a debug assertion on debug builds or wrong data on release
ones.

The problem was a combination of the following factors:

- Item_sum_hybrid::fix_fields() might use the argument
(args[0]) to calculate 'hybrid_field_type' which was later used
to decide how the data should be sent to the client.

- Item_sum::make_field() might use the argument again to
calculate the field's type when sending result set metadata to
the client.

- The argument could be changed in between these two calls via
  Item::set_arg() leading to inconsistent metadata being
  reported.

Here is what was happening for the bug's test case:

1. Item_sum_hybrid::fix_fields() calculates hybrid_field_type
as MYSQL_TYPE_LONGLONG based on args[0] which is an
Item::SUBSELECT_ITEM at that time.

2. A temporary table is created to execute the
query. create_tmp_field_from_item() creates a Field_long object
according to the subselect's max_length.

3. The subselect item in Item_sum_hybrid is replaced by the
Item_field object referencing the newly created Field_long.

4. Item_sum::make_field() rightfully returns the
MYSQL_TYPE_LONG type when calculating the result set metadata.

5. When sending the actual data, Item::send() relies on the
virtual field_type() function which in our case returns
previously calculated hybrid_field_type == MYSQL_TYPE_LONGLONG.

It looks like the only solution is to never refer to the
argument's metadata after the result metadata has been
calculated in fix_fields(), since the argument itself may be
different by then. In this sense, Item_sum::make_field() should
never be used, because it may rely on the argument's metadata
and is only called after fix_fields(). The "default"
implementation in Item::make_field() should be used instead as
it relies only on field_type(), but not on the argument's type.

Fixed by removing Item_sum::make_field() so that the superclass
implementation Item::make_field() is always used.

mysql-test/r/func_group.result:
  Added a test case for bug #54465.
mysql-test/t/func_group.test:
  Added a test case for bug #54465.
sql/item_sum.cc:
  Removed Item_sum::make_field() so that the superclass
  implementation Item::make_field() is always used.
sql/item_sum.h:
  Removed Item_sum::make_field() so that the superclass
  implementation Item::make_field() is always used.

Free memory allocated by the server for all plugins,
with or without deinit() method.

InnoDB Plugin 1.0.11 has been released with MySQL 5.1.50.

After fix for bug 39653 the shortest available secondary index was used for
full table scan. Primary clustered key was used only if no secondary index
can be used. However, when chosen secondary index includes all fields of the
table being scanned it's better to use primary index since the amount of
data to scan is the same but the primary index is clustered.
Now the find_shortest_key function takes this into account.


mysql-test/suite/innodb/r/innodb_mysql.result:
  Added a test case for the bug#55656.
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added a test case for the bug#55656.
sql/sql_select.cc:
  Bug #55656: mysqldump can be slower after bug #39653 fix.
  The find_shortest_key function now prefers clustered primary key
  if found secondary key includes all fields of the table.

Added open log file with FILE_SHARE_DELETE flag on Windows.

sql/log.cc:
  added reopen_fstreams();
  modified redirect_std_streams(): call to sequence of freopen()
  replaced to reopen_fstreams();
  modified flush_error_log(): removed file rename for flushed
  error log file.
sql/mysqld.cc:
  modified main() and init_server_components(): do open log error file
  over call to reopen_fstreams().

Added code resulted in strange linking problem for embedded on Windows
Avoided by not doing this for embedded mode
It's irrelevant for embedded server anyway, --protocol will be ignored

Queries involving predicates of the form "const NOT BETWEEN
not_indexed_column AND indexed_column" could return wrong data
due to incorrect handling by the range optimizer.

For "c NOT BETWEEN f1 AND f2" predicates, get_mm_tree()
produces a disjunction of the SEL_ARG trees for "f1 > c" and
"f2 < c". If one of the trees is empty (i.e. one of the
arguments is not sargable) the resulting tree should be empty
as well, since the whole expression in this case is not
sargable.

The above logic is implemented in get_mm_tree() as follows. The
initial state of the resulting tree is NULL (aka empty). We
then iterate through arguments and compute the corresponding
SEL_ARG tree (either "f1 > c" or "f2 < c"). If the resulting
tree is NULL, it is simply replaced by the generated
tree. Otherwise it is replaced by a disjunction of itself and
the generated tree. The obvious flaw in this implementation is
that if the first argument is not sargable and thus produces a
NULL tree, the resulting tree will simply be replaced by the
tree for the second argument. As a result, "c NOT BETWEEN f1
AND f2" will end up as just "f2 < c".

Fixed by adding a check so that when the first argument
produces an empty tree for the NOT BETWEEN case, the loop is
aborted with an empty tree as a result. The whole idea of using
a loop for 2 arguments does not make much sense, but it was
probably used to avoid code duplication for several BETWEEN
variants.

            within query

The server could crash after materializing a derived table
which requires a temporary table for grouping.

When destroying the temporary table used to execute a query for
a derived table, JOIN::destroy() did not clean up Item_fields
pointing to fields in the temporary table. This led to
dereferencing a dangling pointer when printing out the items
tree later in the outer SELECT.

The solution is an addendum to the patch for bug37362: in
addition to cleaning up items in tmp_all_fields3, do the same
for items in tmp_all_fields1, since now we have an example
where this is necessary.


mysql-test/r/join.result:
  Added test cases for bug#55568 and a duplicate bug #54468.
mysql-test/t/join.test:
  Added test cases for bug#55568 and a duplicate bug #54468.
sql/field.cc:
  Make sure field->table_name is not set to NULL in
  Field::make_field() to avoid assertion failure in 
  Item_field::make_field() after cleaning up items
  (the assertion fired in udf.test when running
  the test suite with the patch applied).
sql/sql_select.cc:
  In addition to cleaning up items in tmp_all_fields3, do the
  same for items in tmp_all_fields1.
  Introduce a new helper function to avoid code duplication.
sql/sql_select.h:
  Introduce a new helper function to avoid code duplication in
  JOIN::destroy().

dict_update_statistics_low(): Create bogus statistics for those
indexes that cannot be accessed because of the innodb_force_recovery
setting.

ha_innobase::info(): Calculate statistics for each index, even if
innodb_force_recovery is set. Fill in bogus data for those indexes
that are not accessed because of the innodb_force_recovery setting.

dict_update_statistics_low(): Create bogus statistics for those
indexes that cannot be accessed because of the innodb_force_recovery
setting.

ha_innobase::info(): Calculate statistics for each index, even if
innodb_force_recovery is set. Fill in bogus data for those indexes
that are not accessed because of the innodb_force_recovery setting.