ISSUE:
------
We pre-allocate the ref_pointer_array before we resolve outer
references. This means that in some cases the
ref_pointer_array may not be large enough to hold all
references created. One such case is aggregate functions in
having clause of a subquery which may add items to select list
of outer query. So it is necessary to consider
select_n_having_items for subqueries while allocating
ref_pointer_array else we will get buffer overflow.

SOLUTION:
---------
Allocate a larger ref_pointer_array by aggregating
select_n_having_items for subqueries.
The fix in sql_yacc.yy is a backport from bug fix 18782905.

              CRASHES WITH AUTO_INCREMENT COLUMN

Description:- Creating a federated table with AUTO_INCREMENT
column using LIKE clause results in a server crash.

Analysis:- Creating a federated table with AUTO_INCREMENT
column using LIKE clause results in a federated server
crash due to the uninitialized connection structure(mysql).
Also due to unassigned connection string for the remote
server, at the time of preparation of "create_info"
structure, the creation of any federated table using LIKE
clause fails with an error, "ERROR 1 (HY000): server name:
'' doesn't exist!". This  bug is not only with
AUTO_INCREMENT but in all creations of federated tables with
LIKE clause.

Fix :- In ha_federated::info(), "mysql->insert_id" assigned
to "stats.auto_increment_value" only when there is an
active connection. This fixes the crash issue. For creating
the federated table with LIKE clause, connection string is
assigned at the time of preparation of "create_info"
structure.

Backporting the patch and the test case fixed as part
of BUG#16041903 and BUG#19683834 respectively.

The problem was that the maximum value of the transaction_prealloc_size
session system variable was ULONG_MAX which meant that it was possible
to cause the server to allocate excessive amounts of memory.

This patch fixes the problem by reducing the maxmimum value of
transaction_prealloc_size and transaction_alloc_block_size down
to 128K.

Note that transactions will still be able to allocate more than
128K if needed, this patch just reduces the amount that can be
preallocated - as well as the maximum size of the incremental
allocation blocks.

Fixing a post push test issue.

Problem Description And Fix:
Inserting a fudged record in mysql.proc with the dbname
column value as test and the name column as empty, will
cause a crash in mysqld when we run the command DROP
DATABASE test.
 During DROP DATABASE test, mysql_rm_db subsequently
calls lock_db_routines. In the routine we fetch the
field 'name' from mysql.proc by calling the underlying
storage engine API in lock_db_routines. This cause NULL
value as the field column of mysql.proc and subsequent
dereference MDL_request::init leads to crash.
Modifying mysql.proc using SQL command by user is not
supported, but in principle, there is a possibility
of mysql.proc getting corrupted which can also lead
to empty fields and arbitary values. The patch fixes
the crash by checking NULL and propagating the appopriate
error code to the user.

Rename a CMake variable in compile_flags.cmake to avoid triggering
CMake 3.1 warning about CMP0054 about interpreting if() arguments
as keywords or variables.

No changes in behavior.

special character sets like utf16, utf32, ucs2.

Analysis: MySQL server does not support few special character sets like
  utf16,utf32 and ucs2 as "client's character set"(eg: utf16,utf32, ucs2).
  It is known limitation listed in the documentation
  http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html.

  The default value for default-character-set parameter is 'auto'
  which means that if the server's character set is not supported,
  then server automatically changes client's character set to
  predefined character-set which is 'latin1' in the current code.

  Eg:
  $ ./mysql -uroot -S$SOCKET_FILE --default-character-set=utf16
  ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'utf16'

  $ ./mysql -uroot -S$SOCKET_FILE will be successfully connected to
  server with 'latin1' as default client side character set.

  When IO thread is trying to connect to Master, it sets server's character
  set as client's character set. When Slave server is started with these
  special character sets, IO thread (which is like a connection to Master)
  fails because of the above said limitation.

 Fix: Now even IO thread also behaves the same as a regular client behaves.
  i.e., If server's character set is not supported as client's character set,
  then set default's client character set(latin1) as client's character set.

Attempt to truncate temporary table using Blackhole storage and
locked by LOCK TABLES caused assertion failure and crashes.

Blackhole is a transaction-aware engine. While creating the temporary
table in transaction-aware engine, temporary table of type
"TRANSACTIONAL_TMP_TABLE" is created. For such temporary tables
a THR_LOCK lock is acquired by the LOCK TABLE operation. References
to them are also added into MYSQL_LOCK::table[] array. Also for
Blackhole engine, flag HTON_CAN_RECREATE is set.

While truncating temporary tables, no locks are taken and
recreate_temporary_table() is called for engines having
"HTON_CAN_RECREATE" in flag.

Function closefrm() is called from the recreate_temporary_table(),
to close the current temporary table. In closefrm(), the lock on
table expected is "F_UNLCK". In debug builds, assert condition on
this fails when lock of type "F_WRLCK" is acquired by LOCK TABLE
operation on temporary tables using Blackhole engine.

In non-debug builds closefrm() simply freed TABLE object leaving
dangling pointer to this object in MYSQL_LOCK::table[] array which
might lead to crashes later.

Fix:
---------
To fix this issue, we now unlock and remove table from MYSQL_LOCK::table[]
array before calling close_temporary_table() in recreate_temporary_table().
This is achieved by calling mysql_lock_remove() function for this table.

Explicitly disable weaker SSL protocols.

Upgrading YaSSL from 2.3.5 to 2.3.7

Reviewed-by : Kristofer Pettersson <kristofer.pettersson@oracle.com>
Reviewed-by : Vamsikrishna Bhagi <vamsikrishna.bhagi@oracle.com>

Fix:
===
Backport Bug#11756194 to mysql-5.5. slave breaks if
'drop database' fails on master and mismatched tables on
slave.

'DROP TABLE <deleted tables>' was binlogged when
'DROP DATABASE' failed and at least one table was deleted
from the database. The log event would lead slave SQL thread
stop if some of the tables did not exist on slave.

After this patch, It is always binlogged with 'IF EXISTS'
option.

		CRASHES ON EVERY START ATTEMPT

Description:
------------
push_warning_printf function is used to print the warning message
to the client. So this function should not invoke while recovering
the server. Moreover current_thd is NULL while starting the server.

Solution:
---------
 - Avoiding the warning to be printed while recovery.
This patch already pushed in mysql-5.6.

	- Moving the test case to correct place.

Patch for 5.5

              CODE

Fixed a failure on pb2 caused by the patch previously
pushed.

Generated new certificates with validity upto 2029.

              CODE

Problem: UDF doesn't handle the arguments properly when they
         are of string type due to a misplaced break.
         The length of arguments is also not set properly
         when the argument is NULL.

Solution: Fixed the code by putting the break at right place
          and setting the argument length to zero when the
          argument is NULL.

Description: When querying a subset of columns from the information_schema.TABLES

Analysis: When information about tables is collected for statements like
"SELECT ENGINE FROM I_S.TABLES" we do not perform full-blown table opens
in SE, instead we only use information from table shares from the Table
Definition Cache or .FRMs. Still in order to simplify I_S implementation
mock TABLE objects are created from TABLE_SHARE during this process.
This is done by calling open_table_from_share() function with special
arguments. Since this function always increments "Opened_tables" counter,
calls to it can be mistakingly interpreted as full-blown table opens in SE.

Note that claim that "'SELECT ENGINE FROM I_S.TABLES' statement doesn't
use Table Cache" is nevertheless factually correct. But it misses the
point, since such statements a) don't use full-blown TABLE objects and
therefore don't do table opens b) still use Table Definition Cache.

Fix: We are now incrementing the counter when db_stat(i.e open flags for ha_open(

we have considered an optimization which would use TABLE objects from
Table Cache when available instead of constructing mock TABLE objects,
but found it too intrusive for stable releases.

Analysis:
--------
Certain queries using intrinsic temporary tables may fail due to
name clashes in the file name for the temporary table when the
'temp-pool' enabled.

'temp-pool' tries to reduce the number of different filenames used for
temp tables by allocating them from small pool in order to avoid
problems in the Linux kernel by using a three part filename:
<tmp_file_prefix>_<pid>_<temp_pool_slot_num>.
The bit corresponding to the temp_pool_slot_num is set in the bit
map maintained for the temp-pool when it used for the file name.
It is cleared after the temp table is deleted for re-use.

The 'create_tmp_table()' function call under error condition
tries to clear the same bit twice by calling 'free_tmp_table()'
and 'bitmap_lock_clear_bit()'. 'free_tmp_table()' does a delete
of the table/file and clears the bit by calling the same function
'bitmap_lock_clear_bit()'.

The issue reported can be triggered under the timing window mentioned
below for an error condition while creating the temp table:
a) THD1: Due to an error clears the temp pool slot number used by it
   by calling 'free_tmp_table'.
b) THD2: In the process of creating the temp table by using an unused
   slot number in the bit map.
c) THD1: Clears the slot number used THD2 by calling
  'bitmap_lock_clear_bit()' after completing the call 'free_tmp_table'.
d) THD3: Uses the slot number used the THD2 since it is freed by THD1.
   When it tries to create the temp file using that slot number,
   an error is reported since it is currently in use by THD2.
   [The error: Error 'Can't create/write to file
   '/tmp/#sql_277e_0.MYD' (Errcode: 17)']

Another issue which may occur in 5.6 and trunk is that:
When the open temporary table fails after its creation(due to ulimit
or OOM error), the file is not deleted. Thus further attempts to use
the same slot number in the 'temp-pool' results in failure.

Fix:
---
a) Under the error condition calling the 'bitmap_lock_clear_bit()'
   function to clear the bit is unnecessary since 'free_tmp_table()'
   deletes the table/file and clears the bit. Hence removed the
   redundant call 'bitmap_lock_clear_bit()' in 'create_tmp_table()'
   This prevents the timing window under which the issue reported
   can be seen.

b) If open of the temporary table fails, then the file is deleted
   thus allowing the temp-pool slot number to be utilized for the
   subsequent temporary table creation.

c) Also if the attempt to create temp table fails since it already
   exists, the temp-pool slot for it is marked as used, to avoid
   the problem from re-appearing.

Change the format of 'git log' to produce INFO_SRC:

commit: <commit hash>
date: 2014-11-12 11:11:10 +0100
build-date: 2014-11-17 15:24:16 +0100
short: <abbreviated commit hash>
branch: mysql-5.5

Use 'git ls-files' to find source files for etags.

Use 'git log -1; git branch' rather than 'bzr version-info'

For 'make dist': only use 'bzr export' if bzr root == ${CMAKE_SOURCE_DIR}
Same thing for git.

               COMMUNICATION PACKETS; FEDERATED TABLE

Description:- Execution of FLUSH TABLES on a federated
table which has been idle for wait_timeout (on the remote
server) + tcp_keepalive_time, fails with an error,
"ERROR 1160 (08S01): Got an error writing communication
packets."

Analysis:- During FLUSH TABLE execution the federated
table is closed which will inturn close the federated
connection. While closing the connection, federated server
tries to communincate with the remote server. Since the
connection was idle for wait_timeout(on the remote server)+
tcp_keepalive_time, the socket gets closed. So this
communication fails because of broken pipe and the error is
thrown. But federated connections are expected to reconnect
silently. And also it cannot reconnect because the 
"auto_reconnect" variable is set to 0 in "mysql_close()".

Fix:- Before closing the federated connection, in
"ha_federated_close()", a check is added which will verify
wheather the connection is alive or not. If the connection
is not alive, then "mysql->net.error" is set to 2 which
will indicate that the connetion is broken. Also the
setting of "auto_reconnect" variable to 0 is delayed and is
done after "COM_QUIT" command.
      
NOTE:- For reproducing this issue, "tcp_keepalive_time" has
to be set to a smaller value. This value is set in the
"/proc/sys/net/ipv4/tcp_keepalive_time" file in Unix
systems. So we need root permission for changing it, which
can't be done through mtr test. So submitting the patch
without mtr test.

Fix broken gcc 4.9.1 debug build by removing end of line noise.

In 5.6+ this issue was already fixed by:
------------------------------------------------------------
revno: 3091
committer: Davi Arnaut <davi.arnaut@oracle.com>
branch nick: mysql-trunk
timestamp: Mon 2011-05-16 11:30:54 -0300
message:
  Fix warnings emitted by Clang.

When building RPMs and using the "rpmbuild" automatic scanning for
Perl dependencies, it might interpret "use hostnames" in the
"mysql_config.pl" script usage comment as a Perl "use" statement.
And then makes the resulting RPMs depends on a non-existing module
Perl "hostnames". The comment was changed to prevent this.

Description:
  Using correct length when moving to next field in cmp_ref. The store
length already includes the length bytes of blobs, which is already considered
earlier for blob types.
	Approved by Mattias, Jimmy [rb-7088] 

Issue :
-------
This seems for some platform -(LONGLONG_MIN) is
not flagged as out of range.

Fix:
----
Fix is backported from mysql-5.6 bug 14314156.
Fixed by adding an explicit test for this value in
Item_func_neg::int_op().

The debug configuration parameter innodb_optimistic_insert_debug
which was introduced for testing corner cases in B-tree handling
had a bug in it. The value 1 would trigger an infinite sequence
of page splits.

Fix: When the value 1 is specified, disable this debug feature.
Approved by Yasufumi Kinoshita

Problem:

In the function dict_foreign_remove_from_cache(), the rb tree was updated
without actually verifying whether the given foreign key object is there in the
rb tree or not.  There can be an existing foreign key object with the same id 
in the rb tree, which must not be removed.  Such a scenario comes when an
attempt is made to add a foreign key object with a duplicate identifier.

Solution:

When the foreign key object is removed from the dictionary cache, ensure
that the foreign key object removed from the rbt is the correct one.

rb#7168 approved by Jimmy and Marko.