Post-push fix, broken build:
sql/rpl_master.cc:1049:70: error: converting ‘false’ to pointer type ‘bool*’ [-Werror=conversion-null]

No commit message

              PLATFORM= MACOSX10.6 X86_64 MAX

bzr merge 5.1=>5.5

              PLATFORM= MACOSX10.6 X86_64 MAX

Problem: The test was failing on pb2's mac machine because
         it was not cleaned up properly. The test checks if
         the command 'start slave until' throws a proper
         error when issued with a wrong number/type of
         parameters. After this,the replication stream was
         stopped using the include file 'rpl_end.inc'.
         The errors thrown earlier left the slave in an
         inconsistent state to be closed by the include
         file which was caught by the mac machine.

Fix: Started slave by invoking start_slave.inc to have a
     working slave before calling rpl_reset.inc

Problem: The test file was not in a good shape. It tested
         start slave until relay log file/pos combination 
         wrongly. A couple of commands were executed at 
         master and replicated at slave. Next, the 
         coordinates in terms of relay log file and pos 
         were noted down followed by reset slave and start
         slave until saved relay log file/pos. Reset slave
         deletes  all relay log files and makes the slave 
         forget its replication position. So, using the 
         saved coordiantes after reset slave is wrong.

Fix: Split the test in two parts:
     a) Test for start slave until master log file/pos and
        checking for correct errors in the failure 
        scenarios.
     b) Test for start slave until relay log file/pos.

Problem: The variables auto_increment_increment and 
         auto_increment_offset were set in the the include
         file rpl_init.inc. This was only configured for 
         some connections that are rarely used by test 
         cases, so likely that it will cause confusion. 
         If replication tests want to setup these variables
         they should do so explicitly.

Fix:
     a) Removed code to set the variables
        auto_increment_increment and auto_increment_offset
        in the include file.
     b) Updated tests files using the same.

Merge from mysql 5.1 to mysql 5.5

In method mysql_binlog_send, right after detecting a EOF in the
read event loop, and before deciding if we should change to a new
binlog file there is a execution window where new events can be
written to the binlog and a rotation can happen. When reaching
the test, the function will then change to a new binlog file
ignoring all the events written in this window. This will result
in events not being replicated.

Only when the binlog is detected as deactivated in the event loop
of the dump thread, can we really know that no more events
remain. For this reason, this test is now made under the log lock
in the beginning of the event loop when reading the events.

The technical problem was that THD::user_var_events_alloc was reset to NULL
from a valid value when a stored program is executed during the PREPARE statement.

The user visible problem was that the server crashed if user issued a PREPARE
statement using some combination of stored functions and user variables.

The fix is to restore THD::user_var_events_alloc to the original value.
This is a minimal fix for 5.5.

More proper patch has been already implemented for 5.6+. It avoids
evaluation of stored functions for the PREPARE phase.

From the user point of view, this bug is a regression, introduced by the patch for WL2649
(Number-to-string conversions), revid: bar@mysql.com-20100211041725-ijbox021olab82nv
However, the code resetting THD::user_var_events_alloc exists even in 5.1.
The WL just changed the way arguments are converted to strings and the bug became visible.

              TLS AND DTLS RECORD PROTOCOLS

Description: Merge from 5.1.

              TLS AND DTLS RECORD PROTOCOLS

Description: In yassl, decryption phase in TLS protocol
             depends on type of padding. This patch
             removes this dependancy and makes error
             generation/decryption process independent
             of padding type.

      
post push fix: 
rpl_stm_until.test was disabled because of
this bug. Enabled and fixed it.

Removed a part of the test that was obsolete.
It tested replication from 4.0 master to 5.0
slave.

      
post push fix: 
rpl_stm_until.test was disabled because of
this bug. Enabled and fixed it.

Removed a part of the test that was obsolete.
It tested replication from 4.0 master to 5.0
slave.

DOWNGRADED FROM 5.6.11 TO 5.6.10

Problem was new syntax not accepted by previous version.

Fixed by adding version comment of /*!50531 around the
new syntax.

Like this in the .frm file:
'PARTITION BY KEY /*!50611 ALGORITHM = 2 */ () PARTITIONS 3'
and also changing the output from SHOW CREATE TABLE to:
CREATE TABLE t1 (a INT)
/*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 ()
PARTITIONS 3 */

It will always add the ALGORITHM into the .frm for KEY [sub]partitioned
tables, but for SHOW CREATE TABLE it will only add it in case it is the non
default ALGORITHM = 1.

Also notice that for 5.5, it will say /*!50531 instead of /*!50611, which
will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail!
If one downgrades an fixed version to the same major version (5.5 or 5.6) the
bug 14521864 will be visible again, but unless the .frm is updated, it will
work again when upgrading again.

Also fixed so that the .frm does not get updated version
if a single partition check passes.

For the error code ER_TOO_LONG_IDENT, the identifier is expected in the my_error call.  So removing this line from here.  

FROM SHOW CREATE

Problem: The length of the internally generated foreign key name 
is not checked. 

Solution: The length of the internally generated foreign key name is
checked.  If it is greater than the allowed limit, an error message
is reported. Also, the constraint name is printed in the same manner
as the table name, using the system charset information.

rb://1969 approved by Marko.

Reverting back the previous changes as they are causing
issues in PB2.

Problem: Sys_vars suite is disabled in mysql-5.1 branch.
Fix: To enable sys_vars suite in mysql-5.1, add it in
mysql-test-run.pl file and also sys_vars suite should be
added to Makefile.am inorder to get that test directory

will not export internal symbols.

srv_export_innodb_status(): Read the purge_sys fields while holding
purge_sys->latch.

Approved by Sunny Bains

             5.1 SERVER

Problem was caused by the COM_CHANGE_USER parsing code. That code ignored
character set number passed in COM_CHANGE_USER packet. Instead
character_set_client values was used. User name was not converted at all.

Fixed by using passed character set number to convert both db and user names.
If COM_CHANGE_USER does not contain character set number then
character_set_client is used to convert both names.

This is a backport of the fix for:

Bug#13633549 HANDLE_FATAL_SIGNAL IN TEST_IF_SKIP_SORT_ORDER/CREATE_SORT_INDEX
Don't invoke the range optimizer for a NULL select.

SUITE FOR 5.1

SYS_VARS suite is not enabled in MTR by default
run. Enabling it with this check-in.

mysql-test/suite/sys_vars/t/disabled.def:
  Till the bugs are fixed, disabling the failed test scripts

Null merge from mysql-5.1

Null merge from mysql-5.1

Null-Merge from mysql-5.5

               DEREFERENCING UT_DBG_NULL_PTR
The abort() call is standard C but InnoDB only uses it in GCC
environments.  UT_DBG_USE_ABORT is not defined the code crashed
by dereferencing a null pointer instead of calling abort().
Other code throughout MySQL including ndb, sql, mysys and other
places call abort() directly.

This bug also affects innodb.innodb_bug14147491.test which fails
randomly on windows because of this issue. 

Approved by marko in http://rb.no.oracle.com/rb/r/1936/

Currently MySQL MSI installer on Windows installs MySQL in 
"per user" mode. It means that if a Windows machine has 
multiple users, they each can install MySQL independently. 
However the default path of MySQL is "C:\Program Files (x86)\MySQL\"
and when two users install MySQL on same machine, the installation
by second user just overwrites the MySQL files. This default shared 
location leads to the issue where if the second user uninstalls MySQL,
the installation files are removed for the first user as well.

In this fix, we are now making the default installation "per machine".
It means that when MySQL is installed with defaults options, all
users can see the shortcuts for MySQL in start menu(since installations 
is for all users). Also when any user relaunches the installer, it will 
consider that action uninstallation rather than installation for that user.

There are command line options in installer that can be used to undo the
"per machine" installation but will not consider that scenario.MySQL 
is a server product and it does not make a lot of sense to install it
differently for each user.