CLIENT

Added a check for a negative second part of the scramble length.

HANDLE_FATAL_SIGNAL IN STRNLEN

Fixed the following bounds checking problems :
1. in check_if_legal_filename() make sure the null terminated
string is long enough before accessing the bytes in it.
Prevents pottential read-past-buffer-end
2. in my_wc_mb_filename() of the filename charset check
for the end of the destination buffer before sending single
byte characters into it.
Prevents write-past-end-of-buffer (and garbaling stack in
the cases reported here) errors.

Added test cases.

1. Clear text password client plugin disabled by default.
2. Added an environment variable LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN, that
when set to something starting with '1', 'Y' or 'y' will enable the clear
text
plugin for all connections.
3. Added a new mysql_options() option : MYSQL_ENABLE_CLEARTEXT_PLUGIN
that takes an my_bool argument. When the value of the argument is non-zero
the clear text plugin is enabled for this connection only.
4. Added an enable-cleartext-plugin config file option that takes a numeric

argument. If the numeric value of the numeric argument is non-zero the
clear
text plugin is enabled for the connection
5. Added a boolean command line option "--enable_cleartext_plugin" to
mysql, mysqlslap and mysqladmin. When specified it will call mysql_options
with the effect of #3
6. Added a new CLEARTEXT option to the connect command in mysqltest.
When specified it will enable the cleartext plugin for usage.
7. Added test cases and updated existing ones that need the clear text
plugin.

executing

The problem is that mysql lacks information about the objects a view
depends on so it can't dump views and tables in the proper order.
Thus it needs to create "stand-in" myisam tables for each view while 
dumping the tables that it later drops and replaces with the actual view
view definition.
But since views can have much more columns than an actual table creating
these stand-in tables may be problematic.

There's no way to portably find out how many columns an mysiam table
can have. It's a complicated formula depending on internal server constants.
Thus we can't have a reliable error check without repeating the logic and 
the formula inside mysqldump.

1. Changed the type of the columns of the stand-in tables mysqldump
makes to satisfy view dependencies from the original type to smallint 
to save on row space.

2. Added a warning on the mysqldump's standard error for a possible 
problems replaying the dump file if the columns of a view exceed 1000.

3. Added a test case.

This is a followup patch for the bug enabling the test
i_binlog.binlog_mysqlbinlog_file_write.test
this was disabled in mysql trunk and mysql 5.5 as in the release
build mysqlbinlog was not debug compiled whereas the mysqld was.
Since have_debug.inc script checks only for mysqld to be debug
compiled, the test was not being skipped on release builds.

We resolve this problem by creating a new inc file 
mysqlbinlog_have_debug.inc which checks exclusively for mysqlbinlog
to be debug compiled. if not it skips the test.
 

mysql-test/include/mysqlbinlog_have_debug.inc:
  new inc file to check if mysqlbinlog is debug compiled.

Details:
 - Modified test case to make sure its run for all and not only
   for archive Storage Engine.

Manual merge from mysql-5.1 to mysql-5.5

This patch fixes various compilation warnings of the type
"error: narrowing conversion of 'x' from 'datatype1' to
'datatype2'

sql/sql_yacc.yy:
  manual merge (backport of WL6219)

Print the warning(note):

 YEAR(x) is deprecated and will be removed in a future release. Please use YEAR(4) instead

on "CREATE TABLE ... YEAR(x)" or "ALTER TABLE MODIFY ... YEAR(x)", where x != 4

make buf_read_page_low() to treat DB_TABLESPACE_DELETED error correctly
rb#1129 approved by Inaam

Introduction of cost based decision on filesort vs index for UPDATE
statements changed detection of the fact that the index used to scan the
table is being updated. The new design missed the case of index merge
when there is no single index to check. That was worked until a recent
change in InnoDB after which it went into infinite recursion if update of
the used index wasn't properly detected.

The fix consists of 'used key being updated' detection code from 5.1.

Patch done by Evgeny Potemkin <evgeny.potemkin@oracle.com>
and transferred into the 5.5.25a release build by Joerg Bruehe.

This changeset is the difference between MySQL 5.5.25 and 5.5.25a.


VERSION:
  Version number change.
sql/sql_update.cc:
  Bug#65745: UPDATE ON INNODB TABLE ENTERS RECURSION
  The check for used key being updated is extended to cover the case when
  index merge is used.

Several fixes :

* sql-common/client.c
Added a validity check of the fields metadata packet sent 
by the server.
Now libmysql will check if the length of the data sent by
the server matches what's expected by the protocol before
using the data.

* client/mysqltest.cc
Fixed the error handling code in mysqltest to avoid sending
new commands when the reading the result set failed (and 
there are unread data in the pipe).

* sql_common.h + libmysql/libmysql.c + sql-common/client.c
unpack_fields() now generates a proper error when it fails.
Added a new argument to this function to support the error 
generation.

* sql/protocol.cc
Added a debug trigger to cause the server to send a NULL
insted of the packet expected by the client for testing 
purposes.

Introduction of cost based decision on filesort vs index for UPDATE
statements changed detection of the fact that the index used to scan the
table is being updated. The new design missed the case of index merge
when there is no single index to check. That was worked until a recent
change in InnoDB after which it went into infinite recursion if update of
the used index wasn't properly detected.

The fix consists of 'used key being updated' detection code from 5.1.

sql/sql_update.cc:
  Bug#14248833: UPDATE ON INNODB TABLE ENTERS RECURSION
  The check for used key being updated is extended to cover the case when
  index merge is used.

              INC_HOST_ERRORS() IS CALLED.
      
Description: Merge from MySQL 5.1 to MySQL 5.5
             Reverting patch 3869 for bug#11753779

              INC_HOST_ERRORS() IS CALLED.

Description: Reverting patch 3755 for bug#11753779

Problem: Some queries with subqueries and a HAVING clause that
consists only of a column not in the select or grouping lists causes
the server to crash.

During parsing, an Item_ref is constructed for the HAVING column. The
name of the column is resolved when JOIN::prepare calls fix_fields()
on its having clause. Since the column is not mentioned in the select
or grouping lists, a ref pointer is not found and a new Item_field is
created instead. The Item_ref is replaced by the Item_field in the
tree of HAVING clauses. Since the tree consists only of this item, the
pointer that is updated is JOIN::having. However,
st_select_lex::having still points to the Item_ref as the root of the
tree of HAVING clauses.

The bug is triggered when doing filesort for create_sort_index(). When
find_all_keys() calls select->cond->walk() it eventually reaches
Item_subselect::walk() where it continues to walk the having clauses
from lex->having. This means that it finds the Item_ref instead of the
new Item_field, and Item_ref::walk() tries to dereference the ref
pointer, which is still null.

The crash is reproducible only in 5.5, but the problem lies latent in
5.1 and trunk as well.

Fix: After calling fix_fields on the having clause in JOIN::prepare(),
set select_lex::having to point to the same item as JOIN::having.

This patch also fixes a bug in 5.1 and 5.5 that is triggered if the
query is executed as a prepared statement. The Item_field is created
in the runtime arena when the query is prepared, and the pointer to
the item is saved by st_select_lex::fix_prepare_information() and
brought back as a dangling pointer when the query is executed, after
the runtime arena has been reclaimed.

Fix: Backport fix from trunk that switches to the permanent arena
before calling Item_ref::fix_fields() in JOIN::prepare().


sql/item.cc:
  Set context when creating Item_field.
sql/sql_select.cc:
  Switch to permanent arena and update select_lex->having.

              INC_HOST_ERRORS() IS CALLED.

Description: Merge from MySQL-5.1 to MySQL-5.5

Null merge from mysql-5.1->mysql-5.5

              INC_HOST_ERRORS() IS CALLED.

Issue       : Sequence of calling inc_host_errors()
              and reset_host_errors() required some
              changes in order to maintain correct
              connection error count.

Solution    : Call to reset_host_errors() is shifted
              to a location after which no calls to
              inc_host_errors() are made.

             CRASHES INNODB | TRX_STATE_NOT_STARTED

The problem was that if DELETE with subselect caused a
deadlock inside InnoDB, this deadlock was not properly
handled by the SQL layer. This meant that the SQL layer
would try to unlock the row after InnoDB had rolled
back the transaction. This caused an assertion inside
InnoDB.

This patch fixes the problem by checking for errors
reported by SQL_SELECT::skip_record() and not calling
unlock_row() if any errors have been reported.

Upmerge from mysql-5.1 -> mysql-5.5

Problem
========
            
Replication breaks in the cases if the event length exceeds 
the size of master Dump thread's max_allowed_packet.
              
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet, on addition of the  
max_event_header length exceeds the max_allowed_packet of the DUMP thread.
This causes the Dump thread to break replication and throw an error.
                      
That can happen e.g with row-based replication in Update_rows event.
            
Fix
====
          
The problem is fixed in 2 steps:

1.) The Dump thread limit to read event is increased to the upper limit
    i.e. Dump thread reads whatever gets logged in the binary log.

2.) On the slave side we increase the the max_allowed_packet for the
    slave's threads (IO/SQL) by increasing it to 1GB.

    This is done using the new server option (slave_max_allowed_packet)
    included, is used to regulate the max_allowed_packet of the  
    slave thread (IO/SQL) by the DBA, and facilitates the sending of
    large packets from the master to the slave.

    This causes the large packets to be received by the slave and apply
    it successfully.

sql/log_event.cc:
  The max_allowed_packet is not evaluated to the new option 
  slave_max_allowed_packet after the fix.
sql/log_event.h:
  Added the new option in the log_event.h file.
sql/mysqld.cc:
  Added a new option to the server.
sql/slave.cc:
  Increasing the session max_allowed_packet to a large value,
  i.e. not taking global(max_allowed) into consideration, for the slave's threads.
sql/sql_repl.cc:
  The dump thread's max_allowed_packet is set to the upper limit
  which makes it independent and it now reads whatever gets 
  logged in the binary log.