for indexes of InnoDB table

Fixes by replacing the PRNG that is used to pick random pages with a 
better one. 

Also adds a configuration option "innodb_use_legacy_cardinality_algorithm"
to enable the fix only when the option is set.

This patch is from http://bugs.mysql.com/file.php?id=11789

  to wrong results
      
3 problems found with DES_ENCRYPT/DES_DECRYPT :

1. The max length was not calculated properly. Fixed in fix_length_and_dec()
2. DES_ENCRYPT had a side effect of sometimes reallocating and changing 
the value of its argument. Fixed by explicitly pre-allocating the necessary
space to pad the argument with trailing '*' (stars) when calculating the 
DES digest.
3. in DES_ENCRYPT the string buffer for the result value was not 
reallocated to the correct size and only string length was assigned to it. 
Fixed by making sure there's enough space to hold the result.

information schema tables are based on internal tmp tables which are removed
after each statement execution. So HANDLER comands can not be used with
information schema.


mysql-test/r/handler.result:
  test result
mysql-test/t/handler.test:
  test case
sql/sql_handler.cc:
  information schema tables are based on internal tmp tables which are removed
  after each statement execution. So HANDLER comands can not be used with
  information schema.

Streamlined how we increase the size of our test table.
The new method shows run time decreased by ~60%.
This is not a guarantee that we will not see test timeouts (the random failures noted in the bug),
but it should significantly reduce the chances of this occurring.

fixed message for 'help' command


client/mysql.cc:
  fixed message for 'help' command

routine does not exist 
      
There is an inconsistency with DROP DATABASE IF EXISTS, DROP TABLE IF
EXISTS and DROP VIEW IF EXISTS: those are binlogged even if the DB or
TABLE does not exist, whereas DROP PROCEDURE IF EXISTS does not. It
would be nice or at least consistent if DROP PROCEDURE/STATEMENT
worked the same too.
      
Fixed DROP PROCEDURE|FUNCTION IF EXISTS by adding a call to
mysql_bin_log.write in mysql_execute_command. Checked also if all 
documented "DROP (...) IF EXISTS" get binlogged.
      
NOTE: This is a 5.0 backport patch as requested by support.

mysql-test/r/rpl_drop_if_exists.result:
  Result file for test case added.
mysql-test/r/rpl_sp.result:
  Updated result file for existing test case that has now extra events in
  binary log (the ones from drop if exists procedure/function).
mysql-test/t/rpl_drop_if_exists.test:
  Added test case for asserting validity of proposed patch.
sql/sql_parse.cc:
  Added call mysql_bin_log.write when lex has drop_if_exists enabled for 
  stored procedures.

The crash happens due to wrong 'digits' variable value(0),
'digits' can not be 0, so the fix is use 1 as min allowed value.


mysql-test/r/insert.result:
  test result
mysql-test/t/insert.test:
  test case
sql/field.cc:
  The crash happens due to wrong 'digits' variable value(0),
  'digits' can not be 0, so the fix is use 1 as min allowed value.

While printing the Max keyfile length 'llstr' call was used which 
was treating the max_key_file_length as negative.

Changing this to ullstr fixes the problem. 
myisamchk output will differ in 32 bit and 64 bit Operating systems 
so its not possible to have test case for this bug.


myisam/myisamchk.c:
  Replaced llstr by ullstr, while converting 
  share->base.max_key_file_length-1 to string.

      
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.

When the thread executing a DDL was killed after finished its
execution but before writing the binlog event, the error code in
the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or
ER_QUERY_INTERRUPTED.

This patch fixed the problem by ignoring the kill status when
constructing the event for DDL statements.

This patch also included the following changes in order to
provide the test case.

 1) modified mysqltest to support variable for connection command

 2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to
    run mysql client against the slave mysqld.

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.