The conformance checker was not taking into
account, and, making concessions for acceptable
incompatibilites in tables created by
versions earlier than 4.1.

The current patch relaxes the conformance
checker to ignore differences in key_alg
and language for tables created by versions
earlier than 4.1.

storage/myisam/ha_myisam.cc:
  Modify check_definition to ignore differences
  in key_alg and language for tables created
  by versions earlier than 4.1.

      
The test started failing following the push for BUG#41541.
Some of the algorithms access bytes beyond the input data
and this can affect up to one byte less than "word size"
which is BITS_SAVED / 8. 
      
Fixed by adding (BITS_SAVED / 8) -1 bytes to buffer size
(i.e. Memory Segment #2) to avoid accessing un-allocated data.

myisam/mi_packrec.c:
  Fixed _mi_read_pack_info() method to allocate (BITS_SAVED/8) - 1 
  bytes to the Memory Segment #2
mysql-test/r/myisampack.result:
  Result file for BUG#43973
mysql-test/t/myisampack.test:
  Testcase for BUG#43973

The patch was originally proposed by Mikael and reviewed by Bar.

1. Test case was rewritten completely.
2. Test covers 3 cases:
 a) do deadlock on slave, wait retries of transaction, unlock slave before lock
timeout;
 b) do deadlock on slave and wait error 'lock timeout exceed' on slave;
 c) same as b) but if of max relay log size = 0;
3. Added comments inline.
4. Updated result file.

The problem is that a SELECT .. FOR UPDATE statement might open
a table and later wait for a impeding global read lock without
noticing whether it is holding a table that is being waited upon
the the flush phase of the process that took the global read
lock.

The same problem also affected the following statements:

LOCK TABLES .. WRITE
UPDATE .. SET (update and multi-table update)
TRUNCATE TABLE ..
LOAD DATA ..

The solution is to make the above statements wait for a impending
global read lock before opening the tables. If there is no
impending global read lock, the statement raises a temporary
protection against global read locks and progresses smoothly
towards completion.

Important notice: the patch does not try to address all possible
cases, only those which are common and can be fixed unintrusively
enough for 5.0.

mysql-test/r/lock_multi.result:
  Add test case result for Bug#43230
mysql-test/t/lock_multi.test:
  Add test case for Bug#43230
sql/sql_lex.cc:
  Initialize flag.
sql/sql_lex.h:
  Add a flag to the lexer.
sql/sql_parse.cc:
  Wait for the global read lock is a write lock is going to be
  taken. The wait is done before opening tables.
sql/sql_yacc.yy:
  Protect against the GRL if its a SELECT .. FOR UPDATE or LOCK TABLES
  .. WRITE statement.

Mysql server crashes because unsafe statements warning is wrongly elevated to error,
which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
Yet the caller believes that binary logging shouldn't touch the status, so it will
set the status also later by my_ok(), my_error() or my_message() seperately
according to the execution result of the statement or transaction.
But the status of Diagnostics_area of the thread is allowed to set only once.

Fixed to clear the error wrongly set by binary logging, but keep the warning message.

mysql-test/suite/binlog/r/binlog_stm_ps.result:
  Change unsafe warning to NOTE level
mysql-test/suite/binlog/r/binlog_unsafe.result:
  Test case result for unsafe statements to ensure mysql sever don't crash
mysql-test/suite/binlog/t/binlog_unsafe.test:
  Test case for unsafe statements to ensure mysql sever don't crash
mysql-test/suite/rpl/r/rpl_skip_error.result:
  Change unsafe warning to NOTE level
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
  Change unsafe warning to NOTE level
mysql-test/suite/rpl/r/rpl_udf.result:
  Change unsafe warning to NOTE level
sql/sql_class.cc:
  the error status of the thread is cleared When a warning is elevated to an error
  because of unsafe warning of binary log.

Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some updated result files for 6.0 and this are the corrsponding resul files for 5.1, so that sys_vars should then run successfully also in 5.1.

Altered the test to accommodate the new behavior of max_allowed_packet.
Had to disconnect / reconnect the default connection for the new value to register.
Re-enabled certain parts of the test that were commented out and added
some setup / cleanup code to ensure proper reset of max_allowed_packet at the end of the test.

Re-recorded the .result file to account for changes to the test.

Bug#32136: mysqld_multi --defaults-file not respected while using \
	--mysqld=mysqld_safe

Revert change that adds "--no-defaults" to mysqld_multi.

This closes Bug#43508 and re-opens Bug#32136.

It was a test case problem: one 'reap' statement was forgotten.

- Link against setargv.obj for wild-card expansion.

- Link against setargv.obj for wild-card expansion.

Original commentary:

Bug #37348: Crash in or immediately after JOIN::make_sum_func_list
            
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
            
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.


mysql-test/r/func_group.result:
  Backport bug #37348 fix 5.1 --> 5.0.
mysql-test/t/func_group.test:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.cc:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/item.h:
  Backport bug #37348 fix 5.1 --> 5.0.
sql/sql_select.cc:
  Backport bug #37348 fix 5.1 --> 5.0.

The problem is that XML functions(items) do not reset null_value
before their execution and further item excution may use
null_value value of the previous result.
The fix is to reset null_value.


mysql-test/r/xml.result:
  test result
mysql-test/t/xml.test:
  test case
sql/item_xmlfunc.cc:
  The problem is that XML functions(items) do not reset null_value
  before their execution and further item excution may use
  null_value value of the previous result.
  The fix is to reset null_value.

Problem: we don't prune a LESS THAN partition if MAXVALUE is given and
given value is equal to a LESS THAN value.

Fix: prune partitions in such cases.


mysql-test/r/partition.result:
  Fix for bug#42944: partition not pruned correctly
    - test result.
mysql-test/t/partition.test:
  Fix for bug#42944: partition not pruned correctly
    - test case.
sql/sql_partition.cc:
  Fix for bug#42944: partition not pruned correctly
    - prune partition if given value is equal to a LESS THAN value
      and it's not a "PARTITION ... LESS THAN MAXVALUE" one.