All tests in the parts suite that use partitioning
on a timezone-dependent expression were commented
out, since it is not valid anymore.

When applying innodb snapshot 1.0.6 the storage engine name for innodb plugin
under windows was changed from INNODB_PLUGIN to INNOBASE.

This is a wrong and changing back the name to INNODB_PLUGIN.

storage/innodb_plugin/CMakeLists.txt:
  Fix for BUG#49502 - CMake error compiling 5.1 on Windows
  
  Change the storage engine name to INNODB_PLUGIN in CMakeLists.txt

5.0 buffer overflow for ER_UPDATE_INFO, or truncated info message in 5.1
      
5.0.86 has a buffer overflow/crash, and 5.1.40 has a truncated message.
      
errmsg.txt contains this:
      
ER_UPDATE_INFO
rum "Linii identificate (matched): %ld  Schimbate: %ld  Atentionari 
(warnings): %ld"
When that is sprintf'd into a buffer of STRING_BUFFER_USUAL_SIZE size,
a buffer overflow can happen.
      
The solution to this is to use MYSQL_ERRMSG_SIZE for the buffer size, 
instead of STRING_BUFFER_USUAL_SIZE. This will allow longer strings. 
To avoid potential crashes, we will also use my_snprintf instead of
sprintf.

sql/sql_update.cc:
  sing MYSQL_ERRMSG_SIZE instead of STRING_BUFFER_USUAL_SIZE.
  Using my_snprintf instead of sprintf.

            timestamp primary key 
 
Since TIMESTAMP values are adjusted by the current time zone  
settings in both numeric and string contexts, using any 
expressions involving TIMESTAMP values as a  
(sub)partitioning function leads to undeterministic behavior of  
partitioned tables. The effect may vary depending on a storage  
engine, it can be either incorrect data being retrieved or  
stored, or an assertion failure. The root cause of this is the  
fact that the calculated partition ID may differ from a  
previously calculated ID for the same data due to timezone  
adjustments of the partitioning expression value. 
 
Fixed by disabling any expressions involving TIMESTAMP values  
to be used in partitioning functions with the follwing two 
exceptions: 
 
1. Creating or altering into a partitioned table that violates 
the above rule is not allowed, but opening existing such tables 
results in a warning rather than an error so that such tables 
could be fixed. 
 
2. UNIX_TIMESTAMP() is the only way to get a 
timezone-independent value from a TIMESTAMP column, because it 
returns the internal representation (a time_t value) of a 
TIMESTAMP argument verbatim. So UNIX_TIMESTAMP(timestamp_column)
is allowed and should be used to fix existing tables if one 
wants to use TIMESTAMP columns with partitioning.

mysql-test/r/partition_bug18198.result:
  Corrected the error.
mysql-test/r/partition_error.result:
  Corrected error texts.
  Added test cases for bug #42849.
mysql-test/t/partition_bug18198.test:
  Corrected error code.
mysql-test/t/partition_error.test:
  Corrected error codes.
  Added test cases for bug #42849.
sql/item.h:
  Added is_timezone_dependent_processor() to Item.
sql/item_func.h:
  Added has_timestamp_args() and the implementation of
  is_timezone_dependent_processor() for Item_func.
sql/item_timefunc.h:
  Added is_timezone_dependent_processor() to 
  Item_func_unix_timestamp.
sql/share/errmsg.txt:
  Renamed ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR to
  ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR to better reflect the
  meaning. Adjusted the error message.
sql/sql_partition.cc:
  Modified fix_fields_part_func() to walk through partitioning
  expression tree with is_timezone_dependent_processor() and issue
  a warning/error if it depends on the timezone settings.
  
  Changed fix_fields_part_func() to a static function since it is
  not used anywhere except sql_partition.cc
sql/sql_partition.h:
  Removed the unneeded declaration of fix_fields_part_func()
  since it is now a static function.
sql/sql_yacc.yy:
  ER_CONST_EXPR_IN_PARTITION_FUNC_ERROR ->
  ER_WRONG_EXPR_IN_PARTITION_FUNC_ERROR.

      
As documented in the bug report, the double checked locking
pattern has inherent issues, and cannot guarantee correct
initialization.

This patch replaces the logic in init_available_charsets()
with the use of pthread_once(3). A wrapper function,
my_pthread_once(), is introduced and is used in lieu of direct
calls to init_available_charsets(). Related defines
MY_PTHREAD_ONCE_* are also introduced.

For the Windows platform, the implementation in lp:sysbench is
ported. For single-thread use, a simple define calls the
function and sets the pthread_once control variable.

Charset initialization is modified to use my_pthread_once().

include/my_no_pthread.h:
  Dummy my_pthread_once() for single thread use.
include/my_pthread.h:
  Declaration for new function my_pthread_once().
mysys/charset.c:
  Logic in init_available_charsets() is simplified. 
  Using my_pthread_once() for all calls to this func.
mysys/my_winthread.c:
  Windows implementation of my_pthread_once().

compatibility, not to change the -D_WIN32_WINNT=0x0501 in 5.1, XP
compatibility.

Windows 2000.
      
      Visual Studio 2003 and 2005 require
        _WIN32_WINNT >= 0x0500 (Win2000)  for TryEnterCriticalSection.

The fix inserts newline and comma characters as appropriate
into the constraint reporting code to match the formatting
required by SHOW CREATE TABLE. Additionally, a erroneously
duplicated copy of check_if_incompatible_data() was removed
from db2i_constraints.cc since the correct version is already
in ha_ibmdb2i.cc.

storage/ibmdb2i/db2i_constraints.cc:
  Bug#49521 SHOW CREATE TABLE on IBMDB2I tables has incorrect fk constraint format
  
  - Insert newline and comma characters into the constraint reporting
    code to match the formatting required by SHOW CREATE TABLE.
  
  - Remove an erroneous copy of check_if_incompatible_data() from
    db2i_constraints.cc.

This fix changes the character set used within the
IBMDB2I handler to hash table names to information
about open tables. Previously, tables with names
that differed only in letter case would hash to the
same data structure. This caused incorrect behavior
or errors when two such tables were in use simultaneously.

mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_49329.result:
  Bug#49329 example (and other) engines use wrong collation for open tables hash
  
  Result file for the test case.
mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_49329.test:
  Bug#49329 example (and other) engines use wrong collation for open tables hash
  
  Test case for the bug fix.
storage/ibmdb2i/ha_ibmdb2i.cc:
  Bug#49329 example (and other) engines use wrong collation for open tables hash
  
  change the character set used within the IBMDB2I
  handler to hash table names to information about
  open tables.

      
The help text for --init-slave=name:
"Command(s) that are executed when a slave connects to this master".
This text indicate that the --init-slave option is set on a  master 
server, and the master server passes the option's argument to slave 
which connects to it. This is wrong. Actually the --init-slave option 
just can be set on a slave server, and then the slave server executes 
the argument each time the SQL thread starts.

Correct the help text for --init-slave option as following:
"Command(s) that are executed by a slave server each time the SQL thread starts."


sql/mysqld.cc:
  Correct the help text for --init-slave option.

The help text for --init-slave=name:
"Command(s) that are executed when a slave connects to this master".
This text indicate that the --init-slave option is set on a  master 
server, and the master server passes the option's argument to slave 
which connects to it. This is wrong. Actually the --init-slave option 
just can be set on a slave server, and then the slave server executes 
the argument each time the SQL thread starts.

Correct the help text for --init-slave option as following:
"Command(s) that are executed by a slave server each time the SQL thread starts."


sql/mysqld.cc:
  Correct the help text for --init-slave option.

SPATIAL and FULLTEXT indexes don't support algorithm
selection. 
Disabled by creating a special grammar rule for these
in the parser.
Added some encasulation of duplicate parser code.

A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
   unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
   constant with a NULL value in the YEAR column;

The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.


mysql-test/r/type_year.result:
  Test case for bug #49480.
mysql-test/t/type_year.test:
  Test case for bug #49480.
sql/item_cmpfunc.cc:
  - The get_year_value() function has been modified to make its
    return value compatible with the get_datetime_value() return
    value (i.e. to convert numeric values into the YYYY0000000000
    (YYYY-00-00 00:00:00) form.
  
  - The Arg_comparator::set_cmp_func method has been modified to
    use the get_year_value function if get_datetime_value() is not
    applicable.
    From now only 2 cases have a special processing there:
    * both comparing items have MYSQL_TYPE_YEAR field type
            or
    * one item have is MYSQL_TYPE_YEAR and other one is
      is_datetime()-compliant.
  
  - New helper function try_year_cmp_func() has been
    added for the better code readability to call from
    Arg_comparator::set_cmp_func().
  
  - The Arg_comparator::compare_year method has been removed
    since get_year_value() is compatible with the old
    Arg_comparator::compare_datetime method that doesn't have
    problems #1-#3 (see whole patch entry commentary).
sql/item_cmpfunc.h:
  - New helper function try_year_cmp_func() has been
    added for the better code readability to call from
    Arg_comparator::set_cmp_func().
  
  - Unnecessary Arg_comparator::year_as_datetime and
    Arg_comparator::compare_year() declarations have been
    removed.

mysql-test/include/kill_query.inc:
  Error 1034 can be generated when change MyISAM table indexes was interrupted
mysql-test/r/rpl_killed_ddl.result:
  table t4 may not exists because the ALTER above was interrupted
mysql-test/t/rpl_killed_ddl.test:
  table t4 may not exists because the ALTER above was interrupted

Arg_comparator uses Item_cache objects to store constants being compared when
they're need a type conversion. Because this cache wasn't initialized properly
Arg_comparator might produce wrong comparison result.

The Arg_comparator::cache_converted_constant function now initializes cache
prior to usage.

mysql-test/r/select.result:
  Added a test case for he bug#49489.
mysql-test/t/select.test:
  Added a test case for he bug#49489.
sql/item_cmpfunc.cc:
  Bug#49489: Uninitialized cache led to a wrong result.
  The Arg_comparator::cache_converted_constant function now initializes cache
  prior to usage.

      
This fix has been proposed by Sergey Petrunya and has been contributed
under SCA by sca@askmonty.org.
      
The cause for this valgrind error is that in the function
add_cond_and_fix() in sql_select.cc an Item_cond_and object is
created. This is marked as fixed but does not have a correct
table_map() attribute. Later, in make_join_select(), if
engine_condition_pushdown is in use, this table map is used and
results in the valgrind error.
      
The fix is to add a call to update_used_tables() in add_cond_and_fix()
so that the table map is updated correctly.
      
This patch is tested by multiple existing tests (e.g. the tests
innodb_mysql, innodb, fulltext, compress all produces this valgrind
warning/error without this fix).


sql/sql_select.cc:
  In add_cond_and_fix() add a call to update_used_tables() to ensure
  the table map is updated.

There are three issues that caused rpl_killed_ddl fails sporadically
in pb2:

 1) thd->clear_error() was not called before create Query event
if operation is executed successfully.
 2) DATABASE d2 might do exist because the statement to CREATE or
ALTER it was killed
 3) because of bug 43353, kill the query that do DROP FUNCTION or
    DROP PROCEDURE can result in SP not found

This patch fixed all above issues by:
 1) Called thd->clear_error() if the operation succeeded.
 2) Add IF EXISTS to the DROP DATABASE d2 statement
 3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.

mysql-test/t/rpl_killed_ddl.test:
  DATABASE d2 might not exists, add IF EXITS to the DROP statement
sql/sql_db.cc:
  Called thd->clear_error() if the operation succeeded

Disabled execution in valgrind to avoid false positive memory
leaks due to fault-injection tests (i.e. call to abort()).

Part 2 : 
There was a special optimization on the ref access method for 
ORDER BY ... DESC that was set without actually looking on the type of the 
selected index for ORDER BY.
Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
to the ASC that has been fixed with the previous fix).