Raise version number after cloning 5.5.30
Raise version number after cloning 5.1.68
Empty version change upmerge
Bug#13997024 SEGV IN SYNC_ARRAY_CELL_PRINT PRINTING OUT LONG SEMAPHORE WAIT DATA

Backport fix from mysql-5.6.
Merge from mysql-5.1 to mysql-5.5.
Bug#16064876    MAIN.KILL FAILS OCCASIONALLY ON SOL10 SPARC64

Analysis:
On solaris, killing a connection which waits on debug sync
(waits on condition variable) is neglected. Subsequent kill
connection to that thread succeeds. Debug sync code is not
included in release build hence it is not an customer issue.
Also verified that except this case, other cases succeed in
main.kill test script. So moving this test to experimental
state on solaris platform only in mysql-5.5 branch.
Bug #16004999 ASSERT STATE == TRX_STATE_NOT_STARTED, UNLOCK_ROW()

Problem:

During the index intersect access method, the SQL layer will access one row,
that satisfies a set of conditions, using an index i1.  And then it will try to
access the same row, with other set of conditions using the next index i2.  If
the fetch from i2 fails (we are talking about an error situation here and not
simply an unmatched row situation), then it will unlock the row accessed via
i1.  This will work in all situations except deadlock error.

When a deadlock happens, InnoDB will rollback the transaction.  InnoDB intimates
the SQL layer about this through the THD::transaction_rollback_request member.
But this is not currently used by the SQL layer.

Solution:

When an error happens, the SQL layer must check the 
THD::transaction_rollback_request member, before calling handler::unlock_row().
We have also added a debug assert in ha_innobase::unlock_row() checking that
it must be called only when the transaction is in active state.

rb#1773 approved by Marko and Sunny.
Bug#11749556: DEBUG ASSERTION WHEN ACCESSING A VIEW AND
              AVAILABLE MEMORY IS TOO LOW 

Analysis:
---------
In function "mysql_make_view", "table->view" is initialized
after parsing(using File_parser::parse) the view definition.
If "::parse" function fails then control is moved to label 
"err:". Here we have assert (table->view == thd->lex). 
This assert fails if "::parse" function fails, as 
table->view is not initialized yet.

File_parser::parse fails if data being parsed is incorrect/
corrupted or when memory allocation fails. In this scenario
its failing because of failure in memory allocation.

Fix:
---------
In case of failure in function "File_parser::parse", moving
to label "err:" is incorrect. Modified code to move
to label "end:".
Merge from 5.1 to 5.5
Bug#11760726: LEFT JOIN OPTIMIZED INTO JOIN LEADS TO
              INCORRECT RESULTS

This is a backport of fix for Bug#13068506.
Bug #14553380 MYSQL C API LIBRARY EXITS AT NET_CLEAR AT NET_SERV.CC:223

Problem description: When client loses the connection to the MySQL server or 
if the server gets shutdown after mysql_stmt_prepare() then the next 
mysql_stmt_prepare() will return an error(as expected) but consecutive call 
mysql_stmt_execute(), will crash the client program. 
The expected behavior would be, it should through an error.

Analysis: The mysql_stmt_prepare() interns calls the function end_server() 
and net->vio and net->buff are freed and set to NULL. Then the next call 
mysql_stmt_execute() will interns call net_clear() where we are "net->vio" 
with out validating it.

Fix: we are validating the net->vio, before calling net_clear().
Merge from 5.1 to 5.5
Bug#15843818  PARTITIONING BY RANGE WITH TO_DAYS ALWAYS
               INCLUDES FIRST PARTITION WHEN PRUNING


PROBLEM
-------

TO_DAYS()/TO_SECONDS() can return NULL for invalid dates which 
was stored in the first partition ,therefore the first partition 
was always included for the scan when range was specified.


FIX
---

The fix is a small optimization which we have included ,which will
prune the scanning of NULL/first partition if the dates specified 
in the range are valid and in the same year and month . TO_SECONDS()
function is not supported in 5.1 so removed it from the fix and test
scripts for mysql-5.1 version.
Bug#15843818  PARTITIONING BY RANGE WITH TO_DAYS ALWAYS
               INCLUDES FIRST PARTITION WHEN PRUNING

[Merge from 5.1 to 5.5]
BUG#11757250: REPLACE(...) INSIDE A STORED PROCEDURE.

Analysis:
--------

REPLACE operation provides incorrect output when
user variable is supplied as an argument and there
are multiple rows on which the operation is performed.

Consider the example below:

SET @var='(( 00000000 ++ 00000000 ))';
SELECT REPLACE(@var, '00000000', table_name) AS a FROM
INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='mysql';

Invalid output:
  +---------------------------------------+
  | REPLACE(@var, '00000000', TABLE_NAME) |
  +---------------------------------------+
  | (( columns_priv ++ columns_priv ))    |
  | (( columns_priv ++ columns_priv ))    |
      ......
      ......
  | (( columns_priv ++ columns_priv ))    |
  | (( columns_priv ++ columns_priv ))    |
  | (( columns_priv ++ columns_priv ))    |
  +---------------------------------------+

The user argument supplied as the string to REPLACE
operation is overwritten after the first iteration
to '(( columns_priv ++ columns_priv ))'.
The overwritten string after the first iteration
is used for the subsequent REPLACE iteration. Since
the pattern string is not found, it returns invalid
output as mentioned above.

Fix:
---
If the Alloced_length is zero, realloc() and create a
copy of the string which is then used for the REPLACE
operation for every iteration.
BUG#11757250: REPLACE(...) INSIDE A STORED PROCEDURE.

Merge from 5.1 to 5.5
- BUG#1608883:  KILLING A QUERY INSIDE INNODB CAUSES IT TO EVENTUALLY CRASH
  WITH AN ASSERTION

  Recently we added check to handle kill query signal for long operating
  queries. 
  While the query interruption is reported it must to ensure cursor is restore
  to proper state for HANDLER interface to work correctly. 
  Normal select query will not face this problem, as on recieving interrupt,
  select query is aborted and new select query result in re-initialization
  (including cursor).

  rb://1836. Approved by Marko.
Merge from mysql-5.1 to mysql-5.5