Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
whether subquery produced any records, this was a documented limitation.

The limitation has been removed (see bugs 8804, 24085, 24127) now
Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
Item_in_optimizer::is_null() invoke val_int() to return correct values for
"NULL IN (SELECT ...)".

Fixing pb failures caused by mtr invokes the test with --tmpdir to which
there are  sensitive operations in the test
and setup_fake_relay_log.inc also needed --secure-file-priv for its own separate
directory.

Fixed with removing SELECT INTO OUTFILE and deploying --exec echo instead in the marco.
The test's opt file should contain --secure-file-priv=$MYSQL_TEST_DIR as the test
operations deal with files located in $MYSQL_TEST_DIR.

      
Overriding a default value of --secure-file-priv on pb.mtr to be $MYSQLTEST_VARDIR which 
makes pb's mtr happy to execute the regression test for the bug.

Overriding a default value of --secure-file-priv on pb.mtr with a value allowable 
the test to pass on pb.

  myisam_repair_threads > 1 causes crash

Problem: parallel repair (myisam_repair_threads > 1) of a myisam
table with two or more fulltext keys that use the same parser may
lead to a server crash. ALTER TABLE ENABLE KEYS is affected as well.

Fix: properly initialize fulltext structures for parallel repair.

Note: 1. there's no deterministic test case.
2. now we call parser->init() for each fulltext key
(not for each fulltext parser used).

           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.

Deleted the opt file. Replaced the sleeps by wait condition. Made some beautyfications.
Inserted review results.   

an additional changeset to remove printing a path name.

It's a regression issue.
The reason of the bug appeared to be an error introduced into 5.1 source code.
A piece of code in Create_file_log_event::do_apply_event() did not have test
coverage which made make test and pb unaware.
      
Fixed with inverting the old value of the return value from 
Create_file_log_event::do_apply_event().
The rpl test suite is extended with `rpl_cross_version' the file to hold 
regression cases similar to the current.

The problem is that the query cache was storing partial results
if the statement failed when sending the results to the client.
This could cause clients to hang when trying to read the results
from the cache as they would, for example, wait indefinitely for
a eof packet that wasn't saved.

The solution is to always discard the caching of a query that
failed to send its results to the associated client.

Extending the existing testcase written for BUG#40949 to verify
repair table operation for compressed tables

clause server fires immediately after creating event and time between create and delete
event sometimes is enough for firing. So adding STARTS clause moves first execution in
future after drop of event
1. Added STARTS clause for CREATE EVENT.
2. Updated result file.

character_set_database !=character_set_server" is fixed.

This does not bring any contents changes, it is purely
metadata which are affected.

Details:

Even within 5.0, most of these changesets did not cause
file contents changes, because they were backports done
for the "service pack" builds of 5.0.66sp1 and 5.0.72sp1.

The "real" changesets are also already present in 5.1,
so this upmerge doesn't change any contents.

The only "real" changeset in 5.0 was a fix of the shell
scripts used to configure bdb (BerkeleyDB).
As we completele removed bdb from the 5.1 sources already,
the affected files are not present in the 5.1 source tree,
so this changeset also does not cause any contents changes.

this should not happen.