Since max_allowed_packet is a read-only variable in 5.1 and up,
disable warnings to avoid unnecessary test case complication.

Set max_allowed_packet to get a consistent error message.

             warnings after uncompressed_length 
 
UNCOMPRESSED_LENGTH() did not validate its argument. In 
particular, if the argument length was less than 4 bytes, 
an uninitialized memory value was returned as a result. 
 
Since the result of COMPRESS() is either an empty string or 
a 4-byte length prefix followed by compressed data, the bug was 
fixed by ensuring that the argument of UNCOMPRESSED_LENGTH() is 
either an empty string or contains at least 5 bytes (as done in 
UNCOMPRESS()). This is the best we can do to validate input 
without decompressing. 

  It turns out that this test case no longer fails with the discrepancy
  in numbers that was the original cause for disabling this test (and showed
  potential genuine issues with the query cache). Therefore
  this test is being enabled after some minor adjustment of error codes and
  messages.

Details:
1. Add missing "disconnect <session>"
2. Take care that the disconnects are finished when the test terminates
3. Replace error names by error numbers
4. Minor beautifying of script code

 
Field_time::get_time() did not initialize some members of 
MYSQL_TIME which led to valgrind warnings when those members 
were accessed in Protocol_simple::store_time(). 
 
It is unlikely that this bug could result in wrong data 
being returned, since Field_time::get_time() initializes the 
'day' member of MYSQL_TIME to 0, so the value of 'day' 
in Protocol_simple::store_time() would be 0 regardless 
of the values for 'year' and 'month'.

In UNION if we use last SELECT without braces and this
SELECT have ORDER BY clause, such clause belongs to
global UNION. It is parsed like last SELECT
part and used further as 'unit->global_parameters->order_list' value.
During DESCRIBE EXTENDED we call select_lex->print_order() for
last SELECT where order fields refer to tmp table 
which already freed. It leads to crash.
The fix is clean up global_parameters->order_list
instead of fake_select_lex->order_list.

  UNIX sockets need to be on a path shorter than 70 characters on some older platofrms.
  MTRv1 tries to fix this by moving the socket to the $TMPDIR, however this causes
  issues with certain tests on Windows.

  Fixed by not applying any hacks on Windows - Windows does not need them.

UNIX sockets need to be on a path shorter than 70 characters on some older platofrms.
MTRv1 tries to fix this by moving the socket to the $TMPDIR, however this causes
issues with certain tests on Windows.

Fixed by not applying any hacks on Windows - Windows does not need them.

with appropriate condition.

Problem: using LOAD_FILE() in some cases we pass a file name string
without a trailing '\0' to fn_format() which relies on that however.
That may lead to valgrind warnings.

Fix: add a trailing '\0' to the file name passed to fn_format().

Also, add CPP so Windows works properly for profiling. Community-server
functionality is required.

Problem: storing "SELECT ... INTO @var ..." results in variables we used val_xxx()
methods which returned results of the current row. 
So, in some cases (e.g. SELECT DISTINCT, GROUP BY or HAVING) we got data
from the first row of a new group (where we evaluate a clause) instead of
data from the last row of the previous group.

Fix: use val_xxx_result() counterparts to get proper results.

backwards, which resulted in the incorrect time being reported at the
end of mysqldump. (Bug #44424, patch by Andrew Hutchings)

which didn't actually do anything. (Bug #39101)

  
The --hexdump option crashed mysqlbinlog when used together  
with the --read-from-remote-server option due to use of  
uninitialized memory.  
  
Since Log_event::print_header() relies on temp_buf to be  
initialized when the --hexdump option is present,  
dump_remote_log_entries() was fixed to setup temp_buf to point  
to the start of a binlog event as done in  
dump_local_log_entries().  
 
The root cause of this bug is identical to the one for 
bug #17654. The latter was fixed in 5.1 and up, so this 
patch is backport of the patches for bug #17654 to 5.0. 
 
Only 5.0 needs a changelog entry. 

adventure.

         with seg fault

Multiple-table DELETE from a table joined to itself may cause
server crash. This was originally discovered with MEMORY engine,
but may affect other engines with different symptoms.

The problem was that the server violated SE API by performing
parallel table scan in one handler and removing records in
another (delete on the fly optimization).