Automerge: mysql-5.1 --> mysql-5.5 

      
There is a race between two threads: user thread and the dump
thread. The former sets a debug instruction that makes the latter wait
before processing an Xid event. There can be cases that the dump
thread has not yet processed the previous Xid event, causing it to
wait one Xid event too soon, thus causing sync_slave_with_master never
to resume.
      
We fix this by moving the instructions that set the debug variable
after calling sync_slave_with_master.

Problem: the test failed because errors were found in the error log.
The test case contains suppressions for an old version of the error message,
but the format of the error message has changed without updating the suppression.
Fix: Update the suppression. Also small fixes to improve the test.


mysql-test/suite/rpl/r/rpl_slave_load_remove_tmpfile.result:
  update result file
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile-slave.opt:
  Use variables instead of .opt files to avoid server restarts.
mysql-test/suite/rpl/t/rpl_slave_load_remove_tmpfile.test:
  1. To fix the bug, we update the regular expression in mtr.add_suppression
     so that it matches the real error text.
  2. Use wait_for_slave_sql_error.inc when we wait for an error.
     This makes the test easier to understand and will produce better
     debug info if the test fails.
  3. Use server variables instead of command line options to set
     the @@GLOBAL.DEBUG variable. This avoids server restarts when
     running the test suite.
  4. Clarify the comment at the top of the file and add bug reference.

of service in prepared statements).

sql/sql_prepare.cc:
  At mysql_stmt_get_longdata(): instead of pushing an internal
  error handler (as done in 5.1-tree) we save, set and restore
  the statement's diagnostics area and warning info.

The problem was that server didn't check resulting size of prepared
statement argument which was set using mysql_send_long_data() API.
By calling mysql_send_long_data() several times it was possible
to create overly big string and thus force server to allocate
memory for it. There was no way to limit this allocation.

The solution is to add check for size of result string against
value of max_long_data_size start-up parameter. When intermediate
string exceeds max_long_data_size value an appropriate error message
is emitted.

We can't use existing max_allowed_packet parameter for this purpose
since its value is limited by 1GB and therefore using it as a limit
for data set through mysql_send_long_data() API would have been an
incompatible change. Newly introduced max_long_data_size parameter
gets value from max_allowed_packet parameter unless its value is
specified explicitly. This new parameter is marked as deprecated
and will be eventually replaced by max_allowed_packet parameter.
Value of max_long_data_size parameter can be set only at server
startup.


mysql-test/t/variables.test:
  Added checking for new start-up parameter max_long_data_size.
sql/item.cc:
  Added call to my_message() when accumulated string exceeds
  max_long_data_size value. my_message() calls error handler
  that was installed in mysql_stmt_get_longdata before call
  to Item_param::set_longdata.
  
  The error handler then sets state, last_error and last_errno
  fields for current statement to values which correspond to
  error which was caught.
sql/mysql_priv.h:
  Added max_long_data_size variable declaration.
sql/mysqld.cc:
  Added support for start-up parameter 'max_long_data_size'.
  This parameter limits size of data which can be sent from
  client to server using mysql_send_long_data() API.
sql/set_var.cc:
  Added variable 'max_long_data_size' into list of variables
  displayed by command 'show variables'.
sql/sql_prepare.cc:
  Added error handler class Set_longdata_error_handler.
  This handler is used to catch any errors that can be
  generated during execution of Item_param::set_longdata().
  
  Source code snippet that makes checking for statement's state 
  during statement execution is moved from Prepared_statement::execute()
  to Prepared_statement::execute_loop() in order not to call
  set_parameters() when statement has failed during
  set_long_data() execution. If this hadn't been done
  the call to set_parameters() would have failed.
tests/mysql_client_test.c:
  A testcase for the bug #56976 was added.

ADHERE TO MAX_ALLOWED_PACKET

Added a check for max_packet_length in CONVERT(, BINARY|CHAR).
Added a test case.

FAILED DROP DATABASE CAN BREAK STATEMENT BASED REPLICATION

The first phase of DROP DATABASE is to delete the tables in the database.
If deletion of one or more of the tables fail (e.g. due to a FOREIGN KEY
constraint), DROP DATABASE will be aborted. However, some tables could
still have been deleted. The problem was that nothing would be written
to the binary log in this case, so any slaves would not delete these tables.
Therefore the master and the slaves would get out of sync.

This patch fixes the problem by making sure that DROP TABLE is written
to the binary log for the tables that were in fact deleted by the failed
DROP DATABASE statement.

Test case added to binlog.binlog_database.test.

Add a missing DBUG_RETURN function test_if_number().

              FAILS IN SET_FIELD_ITERATOR

(Former 59299)

When a PROCEDURE does a natural join, resolving of which columns are
used in the join is done only once; consecutive CALLs to the procedure
will reuse this information:

CREATE PROCEDURE proc() SELECT * FROM t1 NATURAL JOIN v1;
CALL proc();   <- natural join columns resolved here
CALL proc();   <- reuse resolved NJ columns from first CALL

The second CALL knows that it can reuse the resolved NJ columns because
the first CALL sets st_select_lex::first_natural_join_processing=false.
The problem in this bug was that the table the view v1 depends on 
changed between CREATE PROCEDURE and the first CALL: 

CREATE PROCEDURE...
ALTER TABLE t2 CHANGE COLUMN a b CHAR;
CALL proc();   <- error when resolving natural join columns
CALL proc();   <- tries to reuse from first CALL => crash

The fix for this bug is to set first_natural_join_processing= FALSE iff
the natural join columns resolving was successful.


mysql-test/r/sp.result:
  Add test for bug 11766234
mysql-test/t/sp.test:
  Add test for bug 11766234
sql/sql_base.cc:
  Set first_natural_join_processing= FALSE iff the natural join columns resolving was successful.

               INSTALLATION

When starting mysqld as an MS Windows NT service, it crashed 
with "Error 1067: The process terminated unexpectedly".

The problem is that thread local variables are not allocated
and initialized properly when started as a service. When the
server is started as a regular executable, the problem does
not occur.

Analysis showed that this is a regression after the patch for 
Bug#11765237/Bug#11763065.   Before, the thread local storage
was initialized by the call chain:
win_main->my_basic_init->my_thread_basic_global_init->
my_thread_init

When the my_init() structure was changed, this initialization
was moved from win_main to mysqld_main.   When started as
a service win_main is run in a separate thread, which does
not have mysqld_main in its call path, so my_thread_init
is never called for this thread.

Added a call to my_thread_init / my_thread_end in the service
handler function, which solves the problem.

fails when running with ps-protocol).

The problem was that when running in --ps-protocol mode mysqltest.cc
didn't close created prepared statements. So, the plugins could not be
unistalled because there was a prepared statement using them.

A fix is to add a dummy statement that forces mysqltest.cc to close
the last prepared statement (which uses a plugin-defined table).

off bound values were sent to the server this could under some
circumstances lead to a crash on the Windows platform.

This patch corrects the problem by fixing the definition and alterations
of the mysql.user table in the .sql files.

Also included are new result files for tests that examine the name 
column of the mysql.user table.

When a RPM test build in a non-release branch is done,
the $MYSQL_BINDIR variable ends in "/usr"
(rather than in "/usr/lib" as in a RPM release build),
this made test "file_contents" fail.

A branch for this case is added to the test.
The test result is unchanged.



mysql-test/t/file_contents.test:
  Fight a problem in internal test builds:
  
  When a RPM test build in a non-release branch is done,
  the $MYSQL_BINDIR variable ends in "/usr"
  (rather than in "/usr/lib" as in a RPM release build),
  this made test "file_contents" fail.
  
  Because of this, the old logic did not recognize
  that a RPM build is done (trailing '/' missing!)
  and took the tar.gz branch.
  Just removing the trailing '/' from the "/usr" is
  not enough, as the logic for RPMs used to replace
  "/lib" which is not present at all; rather, a new
  branch was added.
  
  To help in case of future problems, the error messages
  for a failing "open()" now also report "$MYSQL_BINDIR".

off bound values were sent to the server this could under some
circumstances lead to a crash on the Windows platform.

Issue:
      SSL_CIPHER set to a specific CIPHER name was not getting picked up by SHOW STATUS Command.

Solution:
      If specific cipher name is specified, avoid overwriting of Cipher List with default Cipher names.


extra/yassl/src/yassl_int.cpp:
  If user specified Cipher name is there, avoid populating default
  cipher names' list.
mysql-test/r/ssl_cipher.result:
  Expected file for ssl_cipher.test test case
mysql-test/t/ssl_cipher-master.opt:
  Server option file for ssl_cipher.test test case.
mysql-test/t/ssl_cipher.test:
  Test case to verify that user specified SSL cipher name is shown in SHOW STATUS Command.