The original fix was done by Ramil Kalimullin on 2009-02-05
All comments are copied from the original fix:


Fix for bug#42014: Crash, name_const with collate

Problem: some queries using NAME_CONST(.. COLLATE ...)
lead to server crash due to failed type cast.

Fix: return the underlying item's type in case of
NAME_CONST(.. COLLATE ...) to avoid wrong casting.


mysql-test/r/func_misc.result:
  Fix for bug#42014: Crash, name_const with coll
    - test result.
mysql-test/t/func_misc.test:
  Fix for bug#42014: Crash, name_const with coll
    - test case.
sql/item.cc:
  Fix for bug#42014: Crash, name_const with coll
    - in case of NAME_CONST('name', 'value' COLLATE collation)
  Item_name_const::type() returns type of 'value' argument 
  to avoid wrong type casting of the Item_name_const items.

The original fix was done by Jonathan Perkin and committed by Georgi Kodinov
on 2009-02-10.
The same day, Georgi added a compilation fix which is already included here.


Original comment:
  Merge libedit 2.11 and related files,
  based on NetBSD CVS as of 2009/02/06 20:09:00.

The original fix was done by Sergey Glukhov on 2009-02-04
All comments are copied from the original fix:


Bug#42495 updatexml: Assertion failed: xpath->context,
                     file .\item_xmlfunc.cc, line 2507
Problem:
   RelativeLocationPath can appear only after a node-set expression
   in the third and the fourth branches of this rule:
     PathExpr :: =  LocationPath
                    | FilterExpr
                    | FilterExpr '/' RelativeLocationPath
                    | FilterExpr '//' RelativeLocationPath
   XPatch code didn't check the type of FilterExpr and crashed.
Fix:
   If FilterExpr is a scalar expression
   (variable reference, literal, number, scalar function call)
   return error.

mysql-test/r/xml.result:
  test result  ((for bug#42495))
mysql-test/t/xml.test:
  test case  ((for bug#42495))
sql/item_xmlfunc.cc:
  Problem:
     RelativeLocationPath can appear only after a node-set expression
     in the third and the fourth branches of this rule:
       PathExpr :: =  LocationPath
                      | FilterExpr
                      | FilterExpr '/' RelativeLocationPath
                      | FilterExpr '//' RelativeLocationPath
     XPatch code didn't check the type of FilterExpr and crashed.
  Fix:
     If FilterExpr is a scalar expression
     (variable reference, literal, number, scalar function call)
     return error.

The original fix was done by Gleb Shchepa on 2009-01-21
All comments are copied from the original fix:


Bug#42188: crash and/or memory corruption with user variables 
           in trigger

Interchangeable calls to the mysql_change_user client function 
and invocations of a trigger changing some user variable caused 
a memory corruption and a crash.

The mysql_change_user API call forces TDH::cleanup() on a server 
that frees user variable entries.
However it didn't reset Item_func_set_user_var::entry to NULL 
because Item_func_set_user_var::cleanup() was not overloaded.
So, Item_func_set_user_var::entry held a pointer to freed memory,
that caused a crash.

The Item_func_set_user_var::cleanup method has been overloaded
to cleanup the Item_func_set_user_var::entry field.

mysql-test/r/user_var.result:
  Added test case for bug #42188.
mysql-test/t/user_var.test:
  Added test case for bug #42188
  and
  After-push test file update (see bug 42321)
sql/item_func.cc:
  Bug#42188: crash and/or memory corruption with user variables
             in trigger
  
  The Item_func_set_user_var::cleanup method has been overloaded
  to cleanup the Item_func_set_user_var::entry field.
sql/item_func.h:
  Bug#42188: crash and/or memory corruption with user variables
             in trigger
  
  The Item_func_set_user_var::cleanup method has been overloaded
  to cleanup the Item_func_set_user_var::entry field.

The original fix was done by Georgi Kodinov on 2009-01-28
All comments are copied from the original fix:


Bug #42366: server-cert.pem expired: "Not After : Jan 27 08:54:13 2009 GMT"

Re-generated the PKI files needed.
Removed the ones that are not needed.
Updated the tests to reference the correct SSL subject.

mysql-test/r/openssl_1.result:
  Bug #42366: Updated the tests to reference the correct SSL subject
mysql-test/std_data/cacert.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/std_data/client-cert.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/std_data/client-key.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/std_data/server-cert-des.pem:
  Bug #42366: Removed the ones that are not needed.
mysql-test/std_data/server-cert.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/std_data/server-key-des.pem:
  Bug #42366: Removed the ones that are not needed.
mysql-test/std_data/server-key.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/std_data/server8k-cert.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/std_data/server8k-key.pem:
  Bug #42366: Re-generated the PKI files needed.
mysql-test/t/openssl_1.test:
  Bug #42366: Updated the tests to reference the correct SSL subject

Cherry-pick fix for bug#40386, "Not flushing query cache after truncate", out of 5.1-bugteam branch.

This fix is r3114 from innodb-5.1-ss3603.

to enable product name and server suffix to differ.

Post-fix test failure: fixed mysqlcheck.test on Windows platforms.


mysql-test/r/mysqlcheck.result:
  fixed mysqlcheck.test on Windows platforms.
mysql-test/t/mysqlcheck.test:
  fixed mysqlcheck.test on Windows platforms.

bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
triggers
and
#41385: Crash when attempting to repair a #mysql50# upgraded table
with triggers.

Problem:
1. trigger code didn't assume a table name may have
a "#mysql50#" prefix, that may lead to a failing ASSERT().
2. "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" failed
for databases with "#mysql50#" prefix if any trigger.
3. mysqlcheck --fix-table-name didn't use UTF8 as a default
character set that resulted in (parsing) errors for tables with
non-latin symbols in their names and definitions of triggers.

Fix:
1. properly handle table/database names with "#mysql50#" prefix.
2. handle --default-character-set mysqlcheck option;
if mysqlcheck is launched with --fix-table-name or --fix-db-name
set default character set to UTF8 if no --default-character-set
option given.

Note: if given --fix-table-name or --fix-db-name option,
without --default-character-set mysqlcheck option
default character set is UTF8.


client/mysqlcheck.c:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - check and set default charset if --default-character-set option
      given.
    - set default charset to "utf8" if there's
      --fix-table-name or --fix-db-name and no --default-character-set.
mysql-test/r/mysqlcheck.result:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - test result.
mysql-test/t/mysqlcheck.test:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - test case.
sql/mysql_priv.h:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - check_n_cut_mysql50_prefix() introduced.
sql/sql_table.cc:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - tablename_to_filename() code split into 2 parts
    - check_n_cut_mysql50_prefix() introduced to cut #mysql50# prefixes,
      used in the trigger code as well.
sql/sql_trigger.cc:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - Table_triggers_list::check_n_load() - checking triggers assume
      a table/database name given may have "#mysql50#" prefix in some cases.
    - Table_triggers_list::change_table_name_in_triggers() -
      create .TRG file in new database directory and delete it in old one,
      as they may differ in case of
      "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME"
    - Table_triggers_list::change_table_name_in_trignames() - remove stale .TRN
      files in #mysql50#dbname directory in case of database upgrade
    - Table_triggers_list::change_table_name() - allow changing trigger's
      database in case of its upgrading
sql/sql_trigger.h:
  Fix for
  bug#33094: Error in upgrading from 5.0 to 5.1 when table contains
  triggers
  and
  #41385: Crash when attempting to repair a #mysql50# upgraded table
  with triggers.
    - new old_db_name parameter added in
      Table_triggers_list::change_table_name_in_trignames() and
      Table_triggers_list::change_table_name_in_triggers()

The next number (AUTO_INCREMENT) field of the table for write
rows events are not initialized, and cause some engines (innodb)
not correctly update the tables's auto_increment value.

This patch fixed this problem by honor next number fields if present.

mysql-test/extra/rpl_tests/rpl_auto_increment.test:
  Add test code for BUG#41986
mysql-test/suite/rpl/r/rpl_auto_increment.result:
  update test result file for BUG#41986
sql/log_event.cc:
  set next_number_field before writing rows, and reset next_number_field after finished writing rows

   41776 type_date.test may fail if run around midnight.
into GCA tree.

   41111 events_bugs fails sporadically on pushbuild
into GCA tree

41932 funcs_1: is_collation_character_set_applicability path too long for tar
into GCA tree

+ add workaround for bug 38124
+ messages into the protocol when sessions are switched
+ replace error numbers by error names
+ reset of system variables to initial values per subtest
+ remove a file created by this test
+ minor improvements in structure and formatting

Added cleanup of status variables to the end of binlog_database.
Re-recorded .result file to account for cleanup statement.
NOTE:  binlog.binlog_innodb also has had an FLUSH STATUS; statement added to it as well, but
adding this cleanup as a preventative measure.

Bug#36428: MY_MUTEX_INIT_FAST is used before initialization

On some thread implementations, we need a fake mutex attri-
bute as a placeholder, which we define as a global variable,
"my_fast_mutexattr".  Well. that must be initialized before 
used in any mutexes, and the ordering of initializations in 
the API function  my_init()  was wrong.

Now, put my_thread_global_init(), which initializes the attri-
butes that mutexes require.

mysql-test/r/commit_1innodb.result:
  Increase commit count for row-based logging.

Bounds-checks and blocksize corrections were applied to user-input,
but constants in the server were trusted implicitly. If these values
did not actually meet the requirements, the user could not set change
a variable, then set it back to the (wonky) factory default or maximum
by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT).

Now checks also apply to the server's presets. Wonky values and maxima
get corrected at startup. Consequently all non-offsetted values the user
sees are valid, and users can set the variable to that exact value if
they so desire.

mysql-test/r/read_buffer_size_basic.result:
  test sets out of bounds value; we now throw a warning for this.
  This is a side-effect: before, the maximum was higher than the
  value we set here. The value was corrected to block-size, the
  maximum was not, hence the value was smaller than the maximum
  in this particular case. Now that we align the maxima at startup,
  the value in SET is larger than the (corrected) maximum, and we
  see a warning in this particular case. "This means we're doing it right."
mysql-test/r/read_rnd_buffer_size_basic.result:
  test sets out of bounds value; we now throw a warning for this.
  This is a side-effect: before, the maximum was higher than the
  value we set here. The value was corrected to block-size, the
  maximum was not, hence the value was smaller than the maximum
  in this particular case. Now that we align the maxima at startup,
  the value in SET is larger than the (corrected) maximum, and we
  see a warning in this particular case. "This means we're doing it right."
mysys/my_getopt.c:
  Do bounds-checking at start-up time so we'll catch and correct
  wonky default values and upper limits.
sql/mysqld.cc:
  If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as
  the lower limit.
storage/innobase/handler/ha_innodb.cc:
  We are setting upper bounds here.
  ~0L gives -1. That is NOT what we want!