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 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.

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.

- 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.

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

more for completeness than for relevance.

Also, update copyright notices.

support-files/mysql.spec.sh:
  Using the occasion of the (late) merge,
  correct the copyright notices.
  
  Note the merge is in 2009, but the code changes were all done in 2008.

updates

Attempt to execute trigger or stored function with multi-UPDATE
which used - but didn't update - a table that was also used by
the calling statement led to an error. Read-only reference to
tables used in the calling statement should be allowed.
 
This problem was caused by the fact that check for conflicting
use of tables in SP/triggers was performed in open_tables(),
and in case of multi-UPDATE we didn't know exact lock type at
this stage.

We solve the problem by moving this check to lock_tables(), so
it can be performed after exact lock types for tables used by
multi-UPDATE are determined.


mysql-test/r/trigger.result:
  Results for the added test case is added.
mysql-test/t/trigger.test:
  A new test case is added, verifying correct table multi-update
  conflict resolution, both read-only and write.
sql/sql_base.cc:
  The check for conflicting use of tables in SP/triggers is moved
  to lock_tables(), to be performed after the exact lock types
  have been determined. Also, an assert is added to open_ltable()
  to ensure this func is not used in a prelocked context.

  
UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns  
to FLOAT/DOUBLE when aggregating data types from the SELECT  
substatements. While there is nothing particularly wrong with  
this behavior, especially when M is greater than the hardware  
precision limits, it could be confusing in cases when all  
SELECT statements in a union have the same  
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision  
specifications listed in the same position.  
  
Since the manual is quite vague on what data type should be  
returned in such cases, the bug was fixed by implementing the  
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)  
to anything else if all SELECT statements in a UNION have the  
same precision for that column.  

mysql-test/r/union.result:
  Added a test case for bug #43432.
mysql-test/t/union.test:
  Added a test case for bug #43432.
sql/field.cc:
  Replaced FLT_DIG+6 and DBL_DIG+7 with a symbolic constant.
sql/item.cc:
  Do not convert FLOAT(M,D)/DOUBLE(M,D) 
  to anything else if all SELECT statements in a UNION have the 
  same precision for that column.
sql/mysql_priv.h:
  Added a symbolic constant for FLT_DIG+6 and DBL_DIG+7.

Problem: commit doesn't delete savepoints if there are no changes 
in the transaction.

Fix: delete them in such cases.


mysql-test/r/innodb_mysql.result:
  Fix for bug #26288: savepoint not deleted, comit on empty transaction
    - test result.
mysql-test/t/innodb_mysql.test:
  Fix for bug #26288: savepoint not deleted, comit on empty transaction
    - test case.
sql/handler.cc:
  Fix for bug #26288: savepoint not deleted, comit on empty transaction
    - call transaction.cleanup() even if nht is 0 to delete 
  possible savepoints.

The problem is that the read and write methods of the shared
memory transport (protocol) didn't react to asynchronous close
events, which could lead to a lock up as the client would wait
(until time out) for a server response that will never come.

The solution is to also wait for close events while waiting
for I/O from or to the server.

mysql-test/r/shm.result:
  Add test case result for Bug#33899
mysql-test/t/shm.test:
  Add test case for Bug#33899
vio/viosocket.c:
  Also wait for close events.

including modifications according to code review
+ backport of the fix for
  Bug 41932 funcs_1: is_collation_character_set_applicability path
                     too long for tar
  which was missing in 5.0 (just a renaming of two files)

      
When add an aliase name after NAME_CONST, the aliase name will be overwrite.
      
NAME_CONST will re-set the field's name only if there isn't an aliase in the
function fix-fields().
If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old
name.

mysql-test/r/func_misc.result:
  Test result.
mysql-test/r/rpl_name_const.result:
  Test case.
mysql-test/t/func_misc.test:
  Add NAME_CONST test.
mysql-test/t/rpl_name_const.test:
  Test result.
sql/item.cc:
  Re-set field's name if the name is autogenerated, that mean without aliase.

due to name_const substitution

Problem:
"In general, statements executed within a stored procedure
are written to the binary log using the same rules that
would apply were the statements to be executed in standalone
fashion. Some special care is taken when logging procedure
statements because statement execution within procedures
is not quite the same as in non-procedure context".

For example, each reference to a local variable in SP's
statements is replaced by NAME_CONST(var_name, var_value).
Queries like
"CREATE TABLE ... SELECT FUNC(local_var ..."
are logged as
"CREATE TABLE ... SELECT FUNC(NAME_CONST("local_var", var_value) ..."
that leads to differrent field names and
might result in "Incorrect column name" if var_value is long enough.

Fix: in 5.x we'll issue a warning in such a case.
In 6.0 we should get rid of NAME_CONST().

Note: this issue and change should be described in the documentation
("Binary Logging of Stored Programs").


mysql-test/r/binlog.result:
  Fix for bug#35383: binlog playback and replication breaks
  due to name_const substitution
    - test result.
mysql-test/t/binlog.test:
  Fix for bug#35383: binlog playback and replication breaks
  due to name_const substitution
    - test case.
sql/sp_head.cc:
  Fix for bug#35383: binlog playback and replication breaks 
  due to name_const substitution
    - set thd->query_name_consts if there's NAME_CONST()
  substitution(s).
sql/sql_parse.cc:
  Fix for bug#35383: binlog playback and replication breaks 
  due to name_const substitution
    - issue a warning if there's NAME_CONST() substitution and
  binary logging is on for "CREATE TABLE ... SELECT ...".

Fine-tuning. Broke out comparison into method by
suggestion of Davi. Clarified comments. Reverting
test-case which I find too brittle; proper test
case in 5.1+.

(Pushing for Azundris)
      
We allow security-contexts with NULL users (for
system-threads and for unauthenticated users).
If a non-SUPER-user tried to KILL such a thread,
we tried to compare the user-fields to see whether
they owned that thread. Comparing against NULL was
not a good idea.
      
If KILLer does not have SUPER-privilege, we
specifically check whether both KILLer and KILLee
have a non-NULL user before testing for string-
equality. If either is NULL, we reject the KILL.

mysql-test/r/rpl_temporary.result:
  Try to have a non-SUPER user KILL a system thread.
mysql-test/t/rpl_temporary.test:
  Try to have a non-SUPER user KILL a system thread.
sql/sql_parse.cc:
  Make sure security contexts of both KILLer *and*
          KILLee are non-NULL before testing for string-equality!

            
After the table is compressed by the myisampack utility,
opening the table by the server produces valgrind warnings.
      
This happens because when we try to read a record into the buffer
we alway assume that the remaining buffer to read is always equal 
to word size(4 or 8 or 2 bytes) we read. Sometimes we have 
remaining buffer size less than word size and trying to read the 
entire word size will end up in valgrind errors.
            
Fixed by reading byte by byte when we detect the remaining buffer 
size is less than the word size.

myisam/mi_packrec.c:
  Fixed fill_buffer() to read byte by byte when the remaining 
  buffer size is less than word size.
mysql-test/r/myisampack.result:
  Result file for BUG#41541
mysql-test/t/myisampack.test:
  Testcase for BUG#41541

                    expired timeout on debx86-b in PB 

Moved the resource-intensive test case for bug #41486 into 
a separate test file to reduce execution time for mysql.test. 


mysql-test/include/wait_until_disconnected.inc:
  Used in mysql-bug41486.test.
mysql-test/r/mysql-bug41486.result:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/r/mysql.result:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/t/mysql-bug41486.test:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/t/mysql.test:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.

                    produce incorrect results for ROUND() 

Added a workaround and a configure check to test whether 
isinf() is affected by the GCC bug #39228. 
       
Since no code in MySQL server is currently affected by that 
bug, the patch is actually a safeguard for possible future 
code modifications. No test cases or changelog entries are 
needed. 


configure.in:
  Added a configure check to test whether isinf() is safe to use
  in C code.
include/my_global.h:
  Added a workaround for GCC bug #39228.

When do 'insert delayed' operation, the time_zone info doesn't be keeped in the row info.
So when we do insert sometime later, time_zone didn't write into binlog.
This will cause wrong result for timestamp column in slave.

Our solution is that adding time_zone info with the delayed-row and
restoring time_zone from row-info when execute that row in the furture by another thread.
So we can write correct time_zone info into binlog and got correct result in slave.


mysql-test/r/rpl_timezone.result:
  Test result
mysql-test/t/rpl_timezone.test:
  Add test for bug#41719
sql/sql_insert.cc:
  Add time_zone info in the delayed-row and restore time_zone when execute the row in the furture by another thread.