BUG#14135002: RPL.RPL_ROTATE_PURGE_DEADLOCK FAILS WITH TIMEOUT ON PB2.

The test case makes use of the fine DEBUG_SYNC facility to synchronize
the execution of different threads.

The problem was that the test was using DEBUG_SYNC to signal the
waiting threads and then right away resetting it (SET
DEBUG_SYNC=RESET). This could in some cases clear the signal before
the waiting thread received it. In those cases the waiting thread
would remain waiting ad eternum, thus causing the test case to
timeout.

We fix this by waiting for the threads to receive the signal and only
then issue the reset.
BUG#14135002

Automerged into latest mysql-5.6
Raise version number after cloning 5.5.39
Raise version number after cloning  and merging back the changes from 5.5
Bug#11758766:MYSQLD CONTINUES OPERATION WITHOUT LOGGING WHEN
BINLOGS CANNOT BE WRITTEN

Post push fix.
Reverting back the file permissions to 0664
Merge mysql-5.6.20-release to mysql-5.6.
Bug #18305270  BACKPORT BUG#18694052 FIX 
               FOR ASSERTION `!M_ORDERED_REC_BUFFER' 
               FAILED TO 5.6 

PROBLEM
-------
Missed to remove record priority queue if 
init_index failed for a partition which
was causing the crash.

FIX
---
Remove priority queue if init_index fails
for partition.
  Bug#18258933 CONCATENATION OF MYSQLBINLOG OUTPUT DOES NOT
               WORK WITH GTID

  Problem:  When mysqlbinlog processes and concatenates
  multiple binary log files into one output file, this
  output file is not in useful state. When it is later
  used for point-in-time recovery, it is producing
  ER_GTID_NEXT_TYPE_UNDEFINED_GROUP "ERROR 1837: When
  @@SESSION.GTID_NEXT is set to a GTID, you must explicitly
  set it to a different value after a COMMIT or ROLLBACK.
  Please check GTID_NEXT variable manual page for detailed
  explanation. Current @@SESSION.GTID_NEXT is 'xyz'".

  Analysis: When mysqlbinlog processes a GTID enabled
  binary log, it outputs SET GTID_NEXT statements. As
  GTID_NEXT is set to 'undefined' when a transaction
  commits (or DDL commits implicitly), this will leave
  GTID_NEXT as 'undefined' when the server has processed
  all output from mysqlbinlog. Also, there can be some
  anonymous statements/transactions at the beginning of
  binary log (i.e., without SET GTID_NEXT statements).   
  When mysqlbinlog processes and concatenates two (or more)
  binary log files into one output file, the combination
  (GTID_NEXT is undefined at the end of first binary log
  and second binary log can contain anonymous transactions)
  will not work and will result in ERROR 1837
  (ER_GTID_NEXT_TYPE_UNDEFINED_GROUP).
 
  Fix: When mysqlbinlog processes second binary log's
       start_log_event, it can output
       "SET GTID_NEXT=AUTOMATIC" if required i.e., if
       previous binary log is leaving the GTID_NEXT state
       in 'undefined' state. In the old code (before this
       patch), when mysqlbinlog processes multiple binary
       log files from multiple command line arguments, it
       used a new PRINT_EVENT_INFO object for each file,
       so the state at the end of the previous file is lost.
       To solve this problem, this patch changes the logic
       to use the same PRINT_EVENT_INFO structure for all
       command line arguments. And to keep track of
       gtid_next state, we are introducing
       is_gtid_next_valid and is_gtid_next_set variables.
       At the beginning of mysqlbinlog process
       is_gtid_next_set is set to false and
       is_gtid_next_valid is set to true.
       When mysqlbinlog encounters a
         i) GTID_LOG_EVENT: it sets is_gtid_next_set to
                            true and is_gtid_next_valid to
                            true.
        ii) XID_LOG_EVENT
             /end_group() : it sets is_gtid_next_valid to
                            false if is_gtid_next_set to
                            true.
       And when mysqlbinlog is processing start_log_event,
       if it finds gtid_next is not valid (i.e., undefined)
       then it produces "SET GTID_NEXT=AUTOMATIC" in the
       output file to avoid mentioned
       ER_GTID_NEXT_TYPE_UNDEFINED_GROUP error and it resets
       is_gtid_next_set to false and is_gtid_next_valid to
       true (the initial values). mysqlbinlog also produces
       'SET GTID_NEXT=AUTOMATIC' in the output file at the
       end of processing all the command line arguments if
       it finds GTID_NEXT is in invalid state.

       After this patch, if you are merging two or more
       binary log files, you will see two differences in
       the output when compared to the before the patch

       a) When mysqlbinlog start processing the second
          binary log file, if required (i.e., if the 
          previous binary log left gtid_next in a invalid
          state), it generates SET GTID_NEXT=AUTOMATIC.
       b) Before the patch, mysqlbinlog outputs session
          variable information for every binary log.
          Now that we will have only one print_event_info
          per run, this session variables value will be
          printed only once *unless there is a change*.
          Example of session variables:
            SET @@session.pseudo_thread_id=999999999/*!*/;
            SET @@session.foreign_key_checks=1
            SET @@session.sql_mode=1073741824/*!*/;
            SET @@session.auto_increment_increment=1,
            SET @@session.auto_increment_offset=1/*!*/;
            SET @@session.lc_time_names=0/*!*/;
            SET @@session.collation_database=DEFAULT/*!*/;
Unconditionally disable dtrace for rpm-oel, barfs on Oracle dtrace
BUG#14135002

Automerged into latest mysql-5.6.
Bug#17453826:ASSERTION ERROR WHEN SETTING FUTURE BINLOG
FILE/POS WITH SEMISYNC

Problem:
========
When DMLs are in progress on the master stopping a slave and
setting ahead binlog name/pos will cause an assert on the
master.

Analysis:
========
Trx1 is waiting for ack on certain position meanwhile change
master command is issued from the slave to master with a
future log file name and position. Upon receipt master's
dump thread assumes that it has received ack till the future
log file and position and clears the active transaction list
and sets the reply_file_name_ and reply_file_pos_ to future
file name and pos. since reply file name and position are
ahead of Trx1's current position Trx1 completes
successfully. Execute a new DML Trx2. During commit Trx2
waits for an ack on some position but the reply file name
and position are already pointing to future file name and
position so this current transaction thinks that it has
already got an ack and no need to wait and proceeds further.
But the active transaction has not actually received any ack
the transaction node is not cleared from active transaction
list. During the exit of commit operation there is an assert
which expects active transaction node to be cleared from the
transaction list which fails this leads to an assert.

Fix:
===
Ideally when a request for change master is received the
request file name and position should be validated for
correctness and only after the validation the transmit_start
hook should be fired.  Hence moved the transmit_start hook
position to appropriate place where it is placed post the
validation of file name and position. Post fix when a future
log file name and position is specified
ER_MASTER_FATAL_ERROR_READING_BINLOG error will be returned
to slave.

Note: During fixing this bug one more bug was identified.

Rpl_semi_sync_master_clients this parameter can become
negative at certain conditions causing UNINSTALL PLUGIN
rpl_semi_sync_master to fail.

'Rpl_semi_sync_master_clients' client is incremented when
dump thread initiates transmission and when a new slave
connection is established. This value is decremented when
dump thread exits and slave gets disconnected. On a certain
condition if IO thread stops due to an error and dump thread
exited before "transmit_start" hook dump thread will still
try to call "transmit_stop" and this will cause
Rpl_semi_sync_master_clients= -1 which is invalid state.
Hence as part of the fix a new flag is introduced such that
"transmit_stop" will be called only when "transmit_start" is
called.
Unconditionally disable dtrace for rpm, barfs on Oracle dtrace
BUG#18779944: MYSQLDUMP BUFFER OVERFLOW

Mysqldump overflows stack buffer when copying table name from commandline arguments resulting in stack corruption and ability to execute arbitrary code.

Fix: Check length of all positional arguments passed to mysqldump is smaller than NAME_LEN.
Note: Mysqldump heavily depends on that database objects (databases, tablespaces, tables, etc) are limited to small size (now it is 64).
BUG#18779944: MYSQLDUMP BUFFER OVERFLOW

Mysqldump overflows stack buffer when copying table name from commandline arguments resulting in stack corruption and ability to execute arbitrary code.

Fix: Check length of all positional arguments passed to mysqldump is smaller than NAME_LEN.
Note: Mysqldump heavily depends on that database objects (databases, tablespaces, tables, etc) are limited to small size (now it is 64).
Bug#17873011 NO DEPRECATION WARNING FOR THREAD_CONCURRENCY

Description:
THREAD_CONCURRENCY is deprecated and there is no 
deprecation warning message while setting this variable
while starting the server.

Analysis:
This variable is specific to Solaris 8 and earlier systems
and is ignored on all other platforms. But since many 
customers, who uses other than Solaris, still has this 
variable in their configuration file, it is important to
have a deprecation warning.

Fix:
THREAD_CONCURRENCY deprecation warning message is added.
Merge from mysql-5.5 to mysql-5.6
Bug #17657223 EXCESSIVE TEMPORARY FILE USAGE IN ALTER TABLE

Analysis:
	Temporary file usage during alter table operation can be avoided
during clustered index rebuild when new primary key follow existing
pk order. So it will reduce the file usage during clustered index rebuild.
Delaying the temporary file creation and log file creation for alter table
operation will lead to avoid the file creation for smaller tables.

	Approved by marko, shaohua (rb-4788)
Bug #19140907 DUPLICATES IN UNIQUE SECONDARY INDEX BECAUSE OF FIX OF BUG#68021

Problem:

When a unique secondary index is scanned for duplicate checking, gap locks
were not taken if the transaction had isolation level <= READ COMMITTED. 
This change was done while fixing Bug #16133801 UNEXPLAINABLE INNODB UNIQUE
INDEX LOCKS ON DELETE + INSERT WITH SAME VALUES (rb#2035). Because of this
the duplicate check logic failed, and resulted in duplicate values in unique
secondary index.

Solution:

When a unique secondary index is scanned for duplicate checking, gap locks
must be taken irrespective of the transaction isolation level.  This is
achieved by reverting rb#2035.

rb#5910 approved by Jimmy
Merge from mysql-5.5 to mysql-5.6