Fixing post push failure

Typo leading to not including the last list values (partition).

Also improved pruning to skip last partition if not used.

rb#4762 approved by Aditya and Marko.

Fixing post push failure

Problem: Uninstallation of semi sync plugin causes replication to
break.

Analysis: A semisync enabled replication is mutual agreement between
Master and Slave when the connection (I/O thread) is established.
Once I/O thread is started and if semisync is enabled on both
master and slave, master appends special magic header to events
using semisync plugin functions and sends it to slave. And slave
expects that each event will have that special magic header format
and reads those bytes using semisync plugin functions.

When semi sync replication is in use if users execute
uninstallation of the plugin on master, slave gets confused while
interpreting that event's content because it expects special 
magic header at the beginning of the event. Slave SQL thread will
be stopped with "Missing magic number in the header" error.

Similar problem will happen if uninstallation of the plugin happens
on slave when semi sync replication is in in use. Master sends
the events with magic header and slave does not know about the
added magic header and thinks that it received a corrupted event.
Hence slave SQL thread stops with "Found  corrupted event" error.

Fix: Uninstallation of semisync plugin will be blocked when semisync
replication is in use and will throw 'ER_UNKNOWN_ERROR' error.
To detect that semisync replication is in use, this patch uses
semisync status variable values.
 > On Master, it checks for 'Rpl_semi_sync_master_status' to be OFF
    before allowing the uninstallation of rpl_semi_sync_master plugin.
    >> Rpl_semi_sync_master_status is OFF when
        >>> there is no dump thread running
        >>> there are no semisync slaves
 > On Slave, it checks for 'Rpl_semi_sync_slave_status' to be OFF
    before allowing the uninstallation of rpl_semi_sync_slave plugin.
    >> Rpl_semi_sync_slave_status is OFF when
       >>> there is no I/O thread running
       >>> replication is asynchronous replication.

Bug #18593044 COMPILE FLAGS NOT PASSED TO DTRACE, BREAKS CROSS BUILD

ARE PERMANENTLY SKIPPED IN 5.5/5.6).

The problem was that some result files were not updated,
so the tests were skipped.

The fix is to record updated result files.

               WHERE ONE OF SELECT* IS DISTINCT FAILS.
ISSUE:
------
There are 2 issues related to explain union.
1. If we have subquery with union of selects. And, one of
   the select need temp table to materialize its results
   then it will replace its query structure with a simple
   select from temporary table. Trying to display new
   internal temporary table scan resulted in crash. But to
   display the query plan, we should save the original
   query structure.
2. Multiple execution of prepared explain statement which
   have union of subqueries resulted in crash. If we have
   constant subqueries, fake select used in union operation
   will be evaluated once before using it for explain.
   During first execution we have set fake select options to
   SELECT_DESCRIBE, but did not reset after the explain.
   Hence during next execution of prepared statement during
   first time evaluation of fake select we had our select
   options as SELECT_DESCRIBE this resulted in improperly
   initialized data structures and crash.

SOLUTION:
---------
1. If called by explain now we save the original query
   structure. And this will be used for displaying.
2. Reset the fake select options after it is called for
   explain of union.

sql/sql_select.cc:
  Reset the fake select options after it is called for explain of union
sql/sql_union.cc:
  If called by explain but not from select_describe and we
  need a temp table, then we create a temp join to preserve
  original query structure.

              BREAKS RBR

Analysis:
--------
A table created using a query of the format:
CREATE TABLE t1 AS SELECT REPEAT('A',1000) DIV 1 AS a;
breaks the Row Based Replication.

The query above creates a table having a field of datatype
'bigint' with a display width of 3000 which is beyond the
maximum acceptable value of 255.

In the RBR mode, CREATE TABLE SELECT statement is
replicated as a combination of CREATE TABLE statement
equivalent to one the returned by SHOW CREATE TABLE and
row events for rows inserted. When this CREATE TABLE event
is executed on the slave, an error is reported:
Display width out of range for column 'a' (max = 255)

The following is the output of 'SHOW CREATE TABLE t1':
CREATE TABLE t1(`a` bigint(3000) DEFAULT NULL)
                  ENGINE=InnoDB DEFAULT CHARSET=latin1;

The problem is due to the combination of two facts:

1) The above CREATE TABLE SELECT statement uses the display
   width of the result of DIV operation as the display width
   of the column created without validating the width for out
   of bound condition.
2) The DIV operation incorrectly returns the length of its first
   argument as the display width of its result; thus allowing
   creation of a table with an incorrect display width of 3000
   for the field.

Fix:
----
This fix changes the DIV operation implementation to correctly
evaluate the display width of its result. We check if DIV's
results estimated width crosses maximum width for integer
value (21) and if yes set it to this maximum value.

This patch also fixes fixes maximum display width evaluation
for DIV function when its first argument is in UCS2.

- Upgrade from MySQL-* packages
- Fix Cflags for el7

              INTO CLIENT_ERRORS ARRAY
              
Analysis:
--------
The client may crash while executing a statement due to
the missing mapping of the server error to it's equivalent
client error.

When trying to reallocate memory for the packet buffer, if
the system is out of memory or the packet buffer is large,
the server errors 'ER_OUT_OF_RESOURCES' or 'ER_PACKET_TOO_LARGE'
is returned respectively. The client error number calculated is
negative and when trying to dereference the array of client 
error messages with the calculated error number, the client
crashes.

Fix:
----
Map the server error returned to it's equivalent client error
prior to dereferencing the array of client error messages.

Note: Test case is not added since it is difficult to simulate
the error condition.

  Bug#18396916 MAIN.OUTFILE_LOADDATA TEST FAILS ON ARM, AARCH64, PPC/PPC64
  
  The recorded results for the failing tests were wrong.
  They were introduced by the patch for
  Bug#30946 mysqldump silently ignores --default-character-set when used with --tab
  
  Correct results were returned for platforms where 'char' is implemented as unsigned.
  This was reported as 
  Bug#46895 Test "outfile_loaddata" fails (reproducible)
  Bug#11755168 46895: TEST "OUTFILE_LOADDATA" FAILS (REPRODUCIBLE)
  The patch for that bug fixed only parts of the problem,
  leaving the incorrect results in the .result file.
  
  Solution: use 'uchar' for field_terminator and line_terminator on all platforms.
  Also: remove some un-necessary casts, leaving the ones we actually need.

It is error to call mysql_thread_init() before libmysql is initialized with mysql_library_init(). Thus to fix this bug we need to detect if library was initialized and return error result if mysql_thread_init() is called with uninitialized library.

Fixed by checking my_thread_global_init_done and returning nonzero if the library is not initialized.

When there is no connection mysql_get_server_version() will return 0
and report CR_COMMANDS_OUT_OF_SYNC error.

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.

mysql-test/suite/binlog/r/binlog_truncate_kill.result:
  Added test case to test the fix for Bug#17942050.
mysql-test/suite/binlog/t/binlog_truncate_kill.test:
  Added test case to test the fix for Bug#17942050.
sql/sql_truncate.cc:
  Check if truncation is successful or not and retun appropriate
  return values so that binlogging can be done based on that.
sql/sql_truncate.h:
  Added a new enum.

Removed unused variable.
Fixed long (>80 lines)

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.

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.

		THE PERFORMANCE UNDER HEAVY INSERT
	Fixing the build problem in 5.5.

		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

               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".

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.

  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.

Don't install solaris specific files on other platforms.

certain pb2 hosts. Removed rpl_innodb_bug28430 from 
default.experimental as BUG can't be repeated

After incrementing the number of pending uncompression operations,
buffer pool zip mutex can be released immediately.

Approved by Vasil. rb#4514

'mysql_config --libs' outputs -L/path/to/library
on SunOS we also want it to output '-R/path/to/library'
in order to find libraries at runtime.


cmake/libutils.cmake:
  Add an informational message, to show dependencies on OS libraries.