Raise version number after cloning 5.5.37
Raise version number after cloning 5.6.17
Bug#17786581:SERVER WRITES INTO WORLD-WRITABLE FILE EVEN
AFTER WARNING ABOUT IT.

Problem:
========
UUID exists in a file named "auto.cnf", make this auto.cnf
file as world writable. The server starts, and it sees the
auto.cnf is world writable and writes a following warning:
Warning: World-writable con-fig file './auto.cnf' is
ignored

A new UUID is generated and the new UUID is once again
written to the same world writable file which is not safe.

Analysis:
========
At the time of starting a fresh server "auto.cnf" file is
read for getting UUID. Before reading the file first its
permissions are checked if they are valid or not. If the
file is found to be world writable its contents are not
read they are ignored a new UUID is generated as if there
was no previous UUID. But the new UUID was again written to
this world writable file which is incorrect.

Fix:
===
Since the world writable file's contents are ignored there
is no necessity to keep this file. The file is deleted.
A new file with appropriate permissions is created during
new UUID generation.
BUG#11754425 -  rpl_innodb_bug28430 times out on 
certain pb2 hosts. Removed rpl_innodb_bug28430 from 
default.experimental as BUG can't be repeated
BUG#11754425 - Upmerge from 5.1 -> 5.5
BUG#11754425 - Upmerge from 5.5 -> 5.6
Bug#18167648: WRONG RESULTS WITH PARTITIONING,
INDEX_MERGE AND NO PK

Index merge intersect/union expects rowid-ordered-retrieval, sorted like
handler::cmp_ref compares records.
I.e. after sorting by KEY it should also be sorted by handler::ref (rowid).

The partitioning engine only sorts by KEY, unless clustered primary key
exists, when it also sorts by PK in case the KEY values are compares as
equal.

This means that for InnoDB tables without primary key or any other engine,
which not clusters by primary key, index merge intersect/union can return
wrong results.

The fix is to also sort by handler::ref if KEY values compares as equal.

To avoid extra sorting when not needed (where rowid-ordered-retrieval is not
needed, like ordinary secondary key scanning)
ha_extra(HA_EXTRA_SECONDARY_SORT_ROWID) is added for index merge
intersect/union.
Bug#18305641 SOLARIS SPECIFIIC FILES INSTALLED ON ALL PLATFORMS

Don't install solaris specific files on other platforms.
merge 5.5 -> 5.6
(actually: patch, since files in 5.5 have wrong ids)
Backport of:
  Bug#17894997 CMAKE WARNING WRT INTERFACE_LINK_LIBRARIES
  Bug#17905155 CMAKE WARNING WHEN GENERATING MAKEFILE
  Bug#71089 CMake warning when generating Makefile

Use old policy for LINK_INTERFACE_LIBRARIES.
merge 5.5 -> 5.6
BUG#18221750 - BACKPORT BUG#14765080 TO 5.6
This is a backport of the BUG#14765080.
Bug#18352347: STATUS OF CHARSET2HTML

This patch removes the charset2html utility.
It was not maintained, not built, not bundled and not complete.
It was not documented outside of the internals documentation.
BUG#17477959 - VIEW COLUMNS EXCEED TABLE LIMITS

Analysis:
--------

Views cannot be restored from a dump file when the
column names and the number of columns of the view
are very large.

'mysqldump' utility creates tables for each of the
view defined inorder to resolve the interdependencies   
between views. These tables are dropped later when the
actual view is created. When a table is created for a
view having large column names and number of columns,
it hits the limitation of 64KB imposed by the '.frm' file
structure for the table. Hence fails with an error
'Too many columns'.

Fix:
----
Instead of creating tables which are dropped later, create
views which are dropped later before the actual view is
created.
Bug#18145032: NO EMPTY TRANSACTION IS CREATED FOR A FILTERED CREATE TEMPORARY TABLE WITH GTIDS
Bug#18095502: NO EMPTY TRANSACTION IS CREATED FOR REPLICATE-IGNORE-DB OR REPLICATE-DO-DB

Background:
When gtid_mode=on, and a transaction is filtered out on the slave,
the GTID of the transaction is still logged on the slave as a so-called
empty transaction (just a GTID followed by BEGIN and then COMMIT). This
is necessary to prevent the transaction from being re-transmitted next
time the slave reconnects or does a fail-over.

Symptom:
 1. If a CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE statement was
    filtered out, no empty transaction was generated.
 2. If the slave has a database filter (--replicate-[do|ignore]-db),
    no empty transaction was generated.

Analysis:
 1. Empty transactions are normally generated after a committing statement
    ends, i.e., after an explicit COMMIT statement or after a statement that
    causes an implicit commit.

    However, CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE have very
    special semantics when it comes to implicit commit. The statements do
    not have the implicit commit flag set and will not commit an ongoing
    transaction. However, they cannot be rolled back.

    So when executed out of transactional context, they effectively perform
    a commit after execution.

    When GTID_MODE=ON, these statements are only allowed outside
    transactional context, and they are not written to the binary log
    within BEGIN/COMMIT statements. Therefore, when such a statement
    has been executed and filtered out, an empty transaction must be
    explicitly committed.

    The reason for the bug is that the current condition for checking
    if empty transaction should be generated is that
    stmt_causes_implicit_commit returns true.

 2. Empty transactions are generated in mysql_parse. However,
    database filters were evaluated before mysql_parse was even
    called.

Fix:
 1. When checking if an empty transaction should be generated, also check
    explicitly for CREATE/DROP TEMPORARY.

 2. Move database filter checking into mysql_parse.

Further bugs:
 3. In the special case that a statement has an 'unexpected' error code
    according to the check in log_event.cc:unexpected_error_code(),
    mysql_parse() is not executed and instead mysql_test_parse_for_slave()
    is executed. This is for the sole purpose of parsing without executing,
    so that an error is only generated on the slave for non-filtered
    tables. Thus, when moving the filter rule checking from
    do_apply_event() into mysql_parse(), we also need to perform the same
    check in mysql_test_parse_for_slave().

Test framework fixes:
- To ease testing of this and other GTID-related bugs, I added the
  test framework files gtid_step_reset.inc and gtid_step_assert.inc.
  gtid_step_assert.inc asserts that the statements executed since
  last gtid_step_reset.inc generated a given number of GTIDs. This
  in turn needed some extra functions in gtid_utils.inc, and I also
  cleaned up and simplified gtid_utils a little and added a test
  case for it.
- Small improvement in mysql-test/include/wait_for_slave_sql_to_stop.inc
  to allow comments after the error code(s).
Bug#18137535 - SERVER CRASH ON CREATE TABLE... SELECT

Analysis:
---------
While creating a table having SELECT, first table from the
table global and local table list is unlinked. Later we
check whether we have any table which is opened for update.
If yes then we return from the function by reporting an
error but without linking back the unlinked table to table
lists.
This works well when the LEX object is not cached. But with
prepared statements and stored programs where LEX object of
the statements is cached. Not linking back the first table
would result in unexpected behaviour on the second execution
of the prepared statement or stored programs. 

In the scenario mentioned in the bug report, the local list
became empty on unlinking the first table on first execution
of stored procedure. The assert to check first_table is
not empty while creating the table fails on next execution
of the stored procedure.

Fix:
----
To resolve this, linking back the unlinked first table to
table lists before reporting an error.

RB:
---
http://rb.no.oracle.com/rb/r/4880/
Bug#18383840: SEGV IN MEMCPY(), HA_PARTITION::POSITION

post-push fix for:
Regression from bug#18167648: WRONG RESULTS WITH PARTITIONING,
INDEX_MERGE MYISAM AND NO PK INNODB

The priority queue is setup in ha_partition::index_init() and also sets
m_sec_sort_by_rowid. But in case the index scan is only done on one
partition, due to pruning, the priority queue will not be used and
the ref will not be copied into the priority queue. So only checking
m_sec_sort_by_rowid is not enough to ensure that the ref is
accessible.

Fixed by checking that ordered scan is used.
Bug#18402229 - Resolve mysql conflict with mysql-community-client
Bug#18319790 QUERY TO INFORMATION_SCHEMA CRASHES SERVER

Before this fix, specially crafted queries
using the INFORMATION_SCHEMA could crash the server.

The root cause was a buffer overflow,
see the (private) bug comments for details.

With this fix, the buffer overflow condition is properly handled,
and the queries involved do return the expected result.
Merge mysql-5.5 --> mysql-5.6