Raise version number after cloning 5.5.37
--BZR--
revision-id: bjorn.munch@oracle.com-20140303141030-b182dtd09ttm11u0
property-audit-revid: bjorn.munch@oracle.com-20140303141030-s10cecu2lwbf5e2d
property-branch-nick: main-55
testament3-sha1: 239f0bfb36d4bbf5104130d856cb7165d9974c5a
BUG#11754425 -  rpl_innodb_bug28430 times out on 
certain pb2 hosts. Removed rpl_innodb_bug28430 from 
default.experimental as BUG can't be repeated

--BZR--
revision-id: namit.sharma@oracle.com-20140304081813-g4mbg1lmqlzb2fw8
property-audit-revid: namit.sharma@oracle.com-20140304081813-uhxrxgtae14t6jih
property-branch-nick: mysql-5.1
testament3-sha1: 4c5cdcca38e1bbe779fd59ca76a1aee8025e6163
BUG#11754425 - Upmerge from 5.1 -> 5.5

--BZR--
revision-id: namit.sharma@oracle.com-20140304082156-al0n453pdcst3k9a
property-audit-revid: namit.sharma@oracle.com-20140304082156-vh2adxaivur2o4qq
property-branch-nick: mysql-5.5
testament3-sha1: 2222a66628a581aa9a0b338d164227d12d74aa48
Bug#18305641 SOLARIS SPECIFIIC FILES INSTALLED ON ALL PLATFORMS

Don't install solaris specific files on other platforms.

--BZR--
revision-id: tor.didriksen@oracle.com-20140304154114-4l8f4e0y87vwenl2
property-audit-revid: tor.didriksen@oracle.com-20140304154114-z3k1hau46g6j4eht
property-branch-nick: 5.5
testament3-sha1: e4f6172d62d888ccb60eddcfa8ff25ad5d6438a8
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.


--BZR--
revision-id: tor.didriksen@oracle.com-20140305120154-ujxkdawpd5b08ubl
property-audit-revid: tor.didriksen@oracle.com-20140305120154-33zdp584ajadgs2r
property-branch-nick: 5.5
testament3-sha1: 267d35f7c6089af857e8071f2877cafc52467ac1
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.

--BZR--
revision-id: marc.alff@oracle.com-20140317165408-y7kcwylc00psy159
property-audit-revid: marc.alff@oracle.com-20140317165408-hrs8wvec33eb6v78
property-branch-nick: mysql-5.5-bug18319790
testament3-sha1: 2cee5fc18f364fab7ab78e0eda8e42afaa38279a
Bug#11759519 - INFINITE HANG WITH 100% CPU USAGE WITH LOAD DATA
               LOCAL AND IMPORT ERRORS

Description:
-----------
This bug happens due to the fact that current algorithm is designed
that in the case of LOCAL load of data, in case of the error, the
remaining part of the file is read in order to return the proper
error message to the client side.

But, the problem with current implementation is that data stream
for the client side is cleared only in the case where line delimiters
exist, which is not a case with, for example fixed width
fields.

Fix:
----
Ported patch provided by Sinisa Milivojevic n bug report for this
issue to 5.5+ versions.

As part of this patch code is changed to clear the data stream
by calling new member function "READ_INFO::skip_data_till_eof".

--BZR--
revision-id: praveenkumar.hulakund@oracle.com-20140319070030-702yfk1n7tuy7223
property-audit-revid: praveenkumar.hulakund@oracle.com-20140319070030-0bc5kvg7sgx0355d
property-branch-nick: mysql-5.5
testament3-sha1: e1b894e3c9dc1ef2cd5021bb6e4c00f8c61de8b2
Merge from mysql-5.5.37-release
--BZR--
revision-id: balasubramanian.kandasamy@oracle.com-20140327101741-n20i5tzzgqv20x2l
property-audit-revid: balasubramanian.kandasamy@oracle.com-20140327101741-15a0al779h8j2xeh
property-authors: balasubramanian.kandasamy@oracle.com
property-branch-nick: mysql-5.5
testament3-sha1: 44c1014815dc6348d191f38125d4d651b183022c
Bug #17858679	TOO MANY TIMES OF MEMSET DECREASE
		THE PERFORMANCE UNDER HEAVY INSERT
Problem:
	There are three memset call to allocate memory for system fields
in each insert.

Solution:
	Instead of calling it in 3 times, we can combine it into
one memset call. It will reduce the CPU usage under heavy insert.

	Approved by Marko rb-4916

--BZR--
revision-id: thirunarayanan.balathandayuth@oracle.com-20140401051613-uck0j44dy8nggv60
property-audit-revid: thirunarayanan.balathandayuth@oracle.com-20140401051613-za8c5yhc3c5aka2y
property-branch-nick: mysql-5.5
testament3-sha1: 1f0743ffea081cd35793940833a47fa4a49459c7
Bug #17858679   TOO MANY TIMES OF MEMSET DECREASE
		THE PERFORMANCE UNDER HEAVY INSERT
	Fixing the build problem in 5.5.

--BZR--
revision-id: thirunarayanan.balathandayuth@oracle.com-20140401060658-ng47y92gdkmsf5zt
property-audit-revid: thirunarayanan.balathandayuth@oracle.com-20140401060658-1krp33vqpori8axq
property-branch-nick: mysql-5.5
testament3-sha1: b07c20c20a28ddb38813756b850b510e24567c15
Support for enterprise packages
--BZR--
revision-id: balasubramanian.kandasamy@oracle.com-20140403105626-wdny5fu7gp8bu0ff
property-audit-revid: balasubramanian.kandasamy@oracle.com-20140403105626-qo49e78x1vg1svj2
property-branch-nick: mysql-5.5.37-repo
testament3-sha1: 2c0d95004e0e9906802a5c6cedd9f27f9ee7d10c
Changed permisison for filter-requires.sh and filter-provides.sh
--BZR--
revision-id: balasubramanian.kandasamy@oracle.com-20140404035849-rvsbvyoa20bq7037
property-audit-revid: balasubramanian.kandasamy@oracle.com-20140404035849-xn5797ubfiz9uuub
property-branch-nick: mysql-5.5.37-repo
testament3-sha1: 6f5dd59ea15c2784f8150e30d7797b14bfe2153e
BUG#18506556. Added sync slave with master for clean-up
--BZR--
revision-id: serge.kozlov@oracle.com-20140404064225-6j33ydtbfj9wn7s4
property-audit-revid: serge.kozlov@oracle.com-20140404064225-u5exkg353bii43jl
property-branch-nick: mysql-5.5
testament3-sha1: 8b823a7f38cc28dda2df4dcae5d4f33159be22c3
Fix Cflags for el7
--BZR--
revision-id: balasubramanian.kandasamy@oracle.com-20140407125144-qe31bnh3mir693g7
property-audit-revid: balasubramanian.kandasamy@oracle.com-20140407125144-v4s9w34o1lfsnuz1
property-branch-nick: mysql-5.5.37-repo
testament3-sha1: fb3a99c8cd149985ef450e31057694e61fbe58f0
updated optflags variable and cmake option for debug build
--BZR--
revision-id: balasubramanian.kandasamy@oracle.com-20140407143609-o1zg6y7mimjh5pjq
property-audit-revid: balasubramanian.kandasamy@oracle.com-20140407143609-84x6zlkiug12hok7
property-branch-nick: mysql-5.5.37-repo
testament3-sha1: 26cc577db146cf35cb39f4023ecc6e34a8b23f6b
Description: When we execute a correlated subquery on an
archive table which is using an auto increment column, the
server hangs. In order to recover the mysqld process, it
has to be terminated abnormally using SIGKILL. The problem
is observed in mysql-5.5.
Bug #18065452 "PREPARING" STATE HOGS CPU WITH ARCHIVE
               + SUBQUERY

Analysis: This happens because the server is trapped inside
an infinite loop in the function,
"subselect_indexsubquery_engine::exec()". This function
resolves the correlated suquery by doing an index lookup
for the appropriate engine. In  case of archive engine,
after reaching the end of records, "table->status" is not
set to STATUS_NOT_FOUND. As a result the loop is not 
terminated.

Fix: The "table->status" is set to STATUS_NOT_FOUND when
the end of records is reached.
--BZR--
revision-id: arun.kuruvila@oracle.com-20140410054031-k0c6q6f027m0093e
property-audit-revid: arun.kuruvila@oracle.com-20140410054031-u3wx05r0ulrg8j1a
property-branch-nick: mysql-5.5
testament3-sha1: 34c261428f244827f72138dc70f86930b6746bcb
Bug #18359924: INNODB AND MYISAM CORRUPTION ON PREFIX INDEXES

The problem was in the validation of the input data for blob types.
When assigned binary data, the character blob types were only checking if 
the length of these data is a multiple of the minimum char length for the 
destination charset. 
And since e.g. UTF-8's minimum character length is 1 (becuase it's 
variable length) even byte sequences that are invalid utf-8 strings (e.g. 
wrong leading byte etc) were copied verbatim into utf-8 columns when
coming from binary strings or fields.
Storing invalid data into string columns was having all kinds of ill effects 
on code that assumed that the encoding data are valid to begin with.

Fixed by additionally checking the incoming binary string for validity when 
assigning it to a non-binary string column.
Made sure the conversions to charsets with no known "invalid" ranges 
are not covered by the extra check.
Removed trailing spaces.

Test case added.
--BZR--
revision-id: georgi.kodinov@oracle.com-20140410101832-wxo4guv28ltp4v3f
property-audit-revid: georgi.kodinov@oracle.com-20140410101832-7lxyrylqs202nme5
property-branch-nick: B18359924-5.5
property-rebase-of: georgi.kodinov@oracle.com-20140410101832-z6xmz2wft8zy859w
testament3-sha1: 2da08eba50ce2517fbf628fa45b680b849fcf77e
Addendum #1 to the fix for bug #18359924

Removed unused variable.
Fixed long (>80 lines)
--BZR--
revision-id: georgi.kodinov@oracle.com-20140411074230-vguwmcotl790m29k
property-audit-revid: georgi.kodinov@oracle.com-20140411074230-u3o1oh7muy1jv0jf
property-branch-nick: mysql-5.5
testament3-sha1: f11471105bd64387151be8233702466267fce0a4
Bug#17942050:KILL OF TRUNCATE TABLE WILL LEAD TO BINARY LOG
WRITTEN WHILE ROWS REMAINS

Problem:
========
When truncate table fails while using transactional based
engines even though the operation errors out we still
continue and log it to binlog. Because of this master has
data but the truncate will be written to binary log which
will cause inconsistency.

Analysis:
========
Truncate table can happen either through drop and create of
table or by deleting rows. In the second case the existing
code is written in such a way that even if an error occurs
the truncate statement will always be binlogged. Which is not
correct.

Binlogging of TRUNCATE TABLE statement should check whether
truncate is executed "transactionally or not". If the table
is transaction based we log the TRUNCATE TABLE only on
successful completion.

If table is non transactional there are possibilities that on
error we could have partial changes done hence in such cases
we do log in spite of errors as some of the lines might have
been removed, so the statement has to be sent to slave.

Fix:
===
Using table handler whether truncate table is being executed
in transaction based mode or not is identified and statement
is binlogged accordingly.
--BZR--
revision-id: sujatha.sivakumar@oracle.com-20140415094725-6uraurl6gbnw8hqo
property-audit-revid: sujatha.sivakumar@oracle.com-20140415094725-myj1tt3x3qx1g4h6
property-branch-nick: Bug17942050_mysql-5.5
property-file-info: ld7:file_id54:binlog_truncate_kill-20140401155242-x7mf7r3p4fq5vjlu-17:message49:Added test case to test the fix for Bug#17942050.4:path53:mysql-test/suite/binlog/r/binlog_truncate_kill.resulted7:file_id54:binlog_truncate_kill-20140306120434-qnkf4m51ywu8n4yw-17:message49:Added test case to test the fix for Bug#17942050.4:path51:mysql-test/suite/binlog/t/binlog_truncate_kill.tested7:file_id49:sql_truncate.cc-20100524123257-5p36wti9gx6o6ygl-37:message122:Check if truncation is successful or not and retun appropriate
property-file-info: return values so that binlogging can be done based on that.4:path19:sql/sql_truncate.cced7:file_id48:sql_truncate.h-20100524123257-5p36wti9gx6o6ygl-47:message17:Added a new enum.4:path18:sql/sql_truncate.hee
testament3-sha1: b323aa9083c02dd6739b9af8472c2a16e6b9483f
Bug #18053212	MYSQL_GET_SERVER_VERSION() CALL WITHOUT A VALID CONNECTION RESULTS IN SEG FAULT

When there is no connection mysql_get_server_version() will return 0
and report CR_COMMANDS_OUT_OF_SYNC error.
--BZR--
revision-id: igor.solodovnikov@oracle.com-20140417133355-sjtbxrhate1322l0
property-audit-revid: igor.solodovnikov@oracle.com-20140417133355-tkxjimx88arxf5lc
property-branch-nick: mysql-5.5
testament3-sha1: a2e713830145d7fd85bb84e034458d56a0013bba