> revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
 > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
 > committer: Gleb Shchepa <gshchepa@mysql.com>
 > branch nick: mysql-5.1-security
 > timestamp: Sun 2010-08-01 22:12:36 +0400
 > Bug #54461: crash with longblob and union or update with subquery
 >
 > Queries may crash, if
 >   1) the GREATEST or the LEAST function has a mixed list of
 >      numeric and LONGBLOB arguments and
 >   2) the result of such a function goes through an intermediate
 >      temporary table.
 >
 > An Item that references a LONGBLOB field has max_length of
 > UINT_MAX32 == (2^32 - 1).
 >
 > The current implementation of GREATEST/LEAST returns REAL
 > result for a mixed list of numeric and string arguments (that
 > contradicts with the current documentation, this contradiction
 > was discussed and it was decided to update the documentation).
 >
 > The max_length of such a function call was calculated as a
 > maximum of argument max_length values (i.e. UINT_MAX32).
 >
 > That max_length value of UINT_MAX32 was used as a length for
 > the intermediate temporary table Field_double to hold
 > GREATEST/LEAST function result.
 >
 > The Field_double::val_str() method call on that field
 > allocates a String value.
 >
 > Since an allocation of String reserves an additional byte
 > for a zero-termination, the size of String buffer was
 > set to (UINT_MAX32 + 1), that caused an integer overflow:
 > actually, an empty buffer of size 0 was allocated.
 >
 > An initialization of the "first" byte of that zero-size
 > buffer with '\0' caused a crash.
 >
 > The Item_func_min_max::fix_length_and_dec() has been
 > modified to calculate max_length for the REAL result like
 > we do it for arithmetical operators.

Fix formatting issues in README file.

EXCEPTIONS-CLIENT from all the places.

> revision-id: alexey.kopytov@sun.com-20100824103548-ikm79qlfrvggyj9h
> parent: sunny.bains@oracle.com-20100816001222-xqc447tr6jwh8c53
> committer: Alexey Kopytov <Alexey.Kopytov@Sun.com>
> branch nick: 5.1-security
> timestamp: Tue 2010-08-24 14:35:48 +0400
> message:
>   Bug #55568: user variable assignments crash server when used
>               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.

backport from 5.1

Problem: a flaw (derefencing a NULL pointer) in the LIKE optimization
code may lead to a server crash in some rare cases.

Fix: check the pointer before its dereferencing.

Updated the README file.

Fix a regression (due to a typo) which caused spurious incorrect
argument errors for long data stream parameters if all forms of
logging were disabled (binary, general and slow logs).

Calculating the estimated number of records for a range scan
may take a significant time, and it was impossible for a user
to interrupt that process by killing the connection or the
query.

Fixed by checking the thread's 'killed' status in
check_quick_keys() and interrupting the calculation process if
it is set to a non-zero value.

(without the unrelated whitespace changes):

  ------------------------------------------------------------------------
  r7009 | jyang | 2010-04-29 20:44:56 +0300 (Thu, 29 Apr 2010) | 6 lines
  
  branches/5.0: Port fix for bug #49238 (Creating/Dropping a temporary
  table while at 1023 transactions will cause assert) from 5.1 to
  branches/5.1. Separate action for return value DB_TOO_MANY_CONCURRENT_TRXS
  from that of DB_MUST_GET_MORE_FILE_SPACE in row_drop_table_for_mysql().
  
  
  ------------------------------------------------------------------------

The problem was that a user could supply supply data in chunks
via the COM_STMT_SEND_LONG_DATA command to prepared statement
parameter other than of type TEXT or BLOB. This posed a problem
since other parameter types aren't setup to handle long data,
which would lead to a crash when attempting to use the supplied
data.

Given that long data can be supplied at any stage of a prepared
statement, coupled with the fact that the type of a parameter
marker might change between consecutive executions, the solution
is to validate at execution time each parameter marker for which
a data stream was provided. If the parameter type is not TEXT or
BLOB (that is, if the type is not able to handle a data stream),
a error is returned.

           line exceeds the limit

The number and/or names of our files for the main test suite
(contents of "mysql-test/t/") now exceeds the command line
length limit on AIX.
Solve the problem by using separate "cp" commands for the
various file name extensions.

Reorder code breaks when finding tests skipped due to --skip-rpl etc.
Add simple test that master_opt is non-empty

Kill mysqltest and call mtr_kill_leftovers() before terminating

Addendum: Work around a compilation failure on Windows due to
          windows.h not being added to the global namespace.

The problem was that the bundled yaSSL library was being built
without thread safety support regardless of the thread safeness
of the compoments linked with it.

The solution is to enable yaSSL thread safety support if any
component (server or client) is to be built with thread support.

Also, generate new certificates for yaSSL's test suite.

The problem is in the Item_func_isnull::update_used_tables() function,
bracket is at the wrong place. Because of that isnull item erroneously
is treated as const item. The fix is to set brackets in the right place.

when an out-of-supported-range date is detected.