In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE
to drop multiple tables causes different errors on master and slave, 
when one or more of these tables do not exist. Because when executed
on slave, it would automatically add IF EXISTS to the query to ignore
all ER_BAD_TABLE_ERROR errors.

To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY
TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after
execution if the query does not expect any errors.

mysql-test/suite/rpl/r/rpl_drop_temp.result:
  Updated for the patch of bug#49137.
mysql-test/suite/rpl/t/rpl_drop_temp.test:
  Added the test file to verify if DROP MULTI TEMPORARY TABLE
  will cause different errors on master and slave, when one or
  more of these tables do not exist.
sql/log_event.cc:
  Added code to handle above cases which are 
  removed from sql_parse.cc
sql/sql_parse.cc:
  Remove the code to issue the 'Unknown table' error, 
  if the temporary table does not exist when dropping 
  it on slave. The above cases decribed in comments
  will be handled later in log_event.cc.

      
In statement-based or mixed-mode replication, use DROP TEMPORARY TABLE
to drop multiple tables causes different errors on master and slave, 
when one or more of these tables do not exist. Because when executed
on slave, it would automatically add IF EXISTS to the query to ignore
all ER_BAD_TABLE_ERROR errors.

To fix the problem, do not add IF EXISTS when executing DROP TEMPORARY
TABLE on the slave, and clear the ER_BAD_TABLE_ERROR error after
execution if the query does not expect any errors.


mysql-test/r/rpl_drop_temp.result:
  Updated for the patch of bug#49137.
mysql-test/t/rpl_drop_temp.test:
  Added the test file to verify if DROP MULTI TEMPORARY TABLE
  will cause different errors on master and slave, when one or
  more of these tables do not exist.
sql/log_event.cc:
  Added code to handle above cases which are
  removed from sql_parse.cc
sql/sql_parse.cc:
  Remove the code to issue the 'Unknown table' error,
  if the temporary table does not exist when dropping
  it on slave. The above cases decribed in comments
  will be handled later in log_event.cc.

           to make the test run gracefully on windows.

There was also a syntax error in windows part of the test.

Several problems fixed : 
1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up
in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of
fields quoted by these expressions pointing to the already freed temporary table
used to calculate the UNION.
Fixed by correctly cleaning up expressions of any depth.

2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in 
EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED
execution. Fixed by not doing the transformation when in EXPLAIN.

3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized
UNION that gets "promoted" to be valid for the whole union, e.g. 
SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE).
This is a case that demonstrates a more general problem of parts of the query being
moved to another level. When doing such transformation late in the optimization run
when most of the flags about the contents of the query are already aggregated it's possible 
to "split" the flags so that they correctly reflect the new queries after the transformation.
In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the 
parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY
that we're to move to the UNION level and what part is about the other parts of the second SELECT.
Fixed by throwing and error when such statements are about to be processed by adding a check 
for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION.
To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real 
global ORDER BY for the UNION outside of the parenthesis.

on re-execution of prepared statement

Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization
is called before each PS execution. However, we don't properly 
initialize its stucture every time before the call.

Fix: properly initialize the sturture used.



mysql-test/r/ps.result:
  Fix for bug#49570: Assertion failed: !(order->used & map) 
  on re-execution of prepared statement
    - test result.
mysql-test/t/ps.test:
  Fix for bug#49570: Assertion failed: !(order->used & map) 
  on re-execution of prepared statement
    - test case.
sql/sql_select.cc:
  Fix for bug#49570: Assertion failed: !(order->used & map) 
  on re-execution of prepared statement
    - set order->used to 0 before each eq_ref_table() call,
  as the function relies on that.

  freezes (win) the server

The check for equality was assuming the field object is always 
created. If it's not it was de-referencing a NULL pointer.
Fixed to use the data in the create object instead.

the declaration of THR_LOCK_myisam_mmap in mi_static 
is redundant as it accessible via the extern declaration 
in include/myisam.h

myisam/mi_static.c:
  Bug#49898 - Fix for bug#37408 introduces a linker error
  
  Remove THR_LOCK_myisam_mmap declaration as it is redundant

If first call of the procedure is failed on
the open_table stage stmt_arena->state is set to
EXECUTED state. On second call(if no errors on
open_table stage) it leads to use of worng memory arena
in find_field_in_view() function as
thd->stmt_arena->is_stmt_prepare_or_first_sp_execute()
returns FALSE for EXECUTED state. The item is created 
not in its own arena and it leads to crash on further
calls of the procedure.
The fix: 
change state of arena only if
no errors on open_table stage happens.


mysql-test/r/sp.result:
  test result
mysql-test/t/sp.test:
  test case
sql/sp_head.cc:
  If first call of the procedure is failed on
  the open_table stage stmt_arena->state is set to
  EXECUTED state. On second call(if no errors on
  open_table stage) it leads to use of worng memory arena
  in find_field_in_view() function as
  thd->stmt_arena->is_stmt_prepare_or_first_sp_execute()
  returns FALSE for EXECUTED state. The item is created 
  not in its own arena and it leads to crash on further
  calls of the procedure.
  The fix: 
  change state of arena only if
  no errors on open_table stage happens.

and also applying 5.1-ss6355

Detailed revision comments:

r6324 | jyang | 2009-12-17 06:54:24 +0200 (Thu, 17 Dec 2009) | 8 lines
branches/5.1: Fix bug #47814 - Diagnostics are frequently not
printed after a long lock wait in InnoDB. Separate out the 
lock wait timeout check thread from monitor information
printing thread.

rb://200 Approved by Marko.

r6349 | marko | 2009-12-22 11:09:54 +0200 (Tue, 22 Dec 2009) | 3 lines
branches/5.1: lock_print_info_summary(): Remove a reference to
innobase_mysql_end_print_arbitrary_thd() that should have been
removed in r6347 when removing the function.

r6350 | marko | 2009-12-22 11:11:09 +0200 (Tue, 22 Dec 2009) | 1 line
branches/5.1: Remove an obsolete declaration of LOCK_thread_count.

At the end of execution top level join execution
we cleanup this join with true argument.
It leads to underlying join cleanup(subquery) with true argument too
and to tmp_table_param->field array cleanup which is required later.
The problem is that Item_func_set_user_var does not set
result_filed which leads to unnecessary repeated excution of subquery
on final stage.
The fix is to set result_field for Item_func_set_user_var.


mysql-test/r/count_distinct.result:
  test result
mysql-test/r/user_var.result:
  test result
mysql-test/t/count_distinct.test:
  test case
mysql-test/t/user_var.test:
  test case
sql/item_func.cc:
  At the end of execution top level join execution
  we cleanup this join with true argument.
  It leads to underlying join cleanup(subquery) with true argument too
  and to tmp_table_param->field array cleanup which is required later.
  The problem is that Item_func_set_user_var does not set
  result_filed which leads to unnecessary repeated excution of subquery
  on final stage.
  The fix is to set result_field for Item_func_set_user_var.

not address the printouts issue

Detailed revision comments:

r6310 | marko | 2009-12-15 15:23:54 +0200 (Tue, 15 Dec 2009) | 30 lines
branches/5.1: Merge r4922 from branches/zip.

This the fix for the first part of Bug #41609 from InnoDB Plugin to
the built-in InnoDB in MySQL 5.1. This allows InnoDB Hot Backup to
back up a database while the built-in InnoDB in MySQL 5.1 is creating
temporary tables. (This fix does not address the printouts about
missing .ibd files for temporary tables at InnoDB startup, which was
committed to branches/zip in r6252.)

rb://219 approved by Sunny Bains.

branches/zip: Distinguish temporary tables in MLOG_FILE_CREATE.
This addresses Mantis Issue #23 in InnoDB Hot Backup and some
of MySQL Bug #41609.

In MLOG_FILE_CREATE, we need to distinguish temporary tables, so that
InnoDB Hot Backup can work correctly.  It turns out that we can do this
easily, by using a bit of the previously unused parameter for page number.
(The page number parameter of MLOG_FILE_CREATE has been written as 0 
ever since MySQL 4.1, which introduced MLOG_FILE_CREATE.)

MLOG_FILE_FLAG_TEMP: A flag for indicating a temporary table in
the page number parameter of MLOG_FILE_ operations.

fil_op_write_log(): Add the parameter log_flags.

fil_op_log_parse_or_replay(): Add the parameter log_flags.
Do not replay MLOG_FILE_CREATE when MLOG_FILE_FLAG_TEMP is set in log_flags.
This only affects ibbackup --apply-log.  InnoDB itself never replays file
operations.

Detailed revision comments:

r6306 | calvin | 2009-12-14 15:12:46 +0200 (Mon, 14 Dec 2009) | 5 lines
branches/5.1: fix bug#49267: innodb-autoinc.test fails on windows
because of different case mode

There is no change to the InnoDB code, only to fix test case by
changing "T1" to "t1".

When the $diff_statement variable for diff_master_slave.inc was
put in multiple lines, the rear part of the statement would be 
missing when being executed on Windows systems.

Fixed the problem by always putting the value for $diff_statement
in one line.

mysql-test/suite/rpl/t/rpl_killed_ddl.test:
  putting the statement for $diff_statement variable in one line.

unnecessarily

Changing an instance of the define that was missed
in the original commit due to the fact that it was
misspelled.

Post-merge fix: wait for statement result before disconnecting.
Otherwise, the statement might affect unrelated tests.

mysql-test/t/lock_multi.test:
  Reap statement status.

MySQL 5.1 specific fixes.

Bug#35589 SET PASSWORD caused a crash
Bug#35591 FLUSH PRIVILEGES caused a crash
      
A race condition on the privilege hash tables (proc_priv_hash
and func_priv_hash) caused one thread to try to delete elements
that had already been deleted by another thread.
      
The bug was caused by reading and saving the pointers to 
the hash tables outside mutex protection.  This led to an
inconsistency where a thread copied a pointer to a hash,
another thread did the same, the first thread then deleted
the hash, and the second then crashed when it in turn tried to
delete the deleted hash.
      
The fix is to ensure that operations on the shared hash structures
happens under mutex protection (moving the locking up a little)

The problem is a somewhat common misusage of the strmake function.
The strmake(dst, src, len) function writes at most /len/ bytes to
the string pointed to by src, not including the trailing null byte.
Hence, if /len/ is the exact length of the destination buffer, a
one byte buffer overflow can occur if the length of the source
string is equal to or greater than /len/.

client/mysqldump.c:
  Make room for the trailing null byte.
libmysql/libmysql.c:
  Add comment, there is enough room in the buffer.
  Increase buffer length, two strings are concatenated.
libmysqld/lib_sql.cc:
  Make room for the trailing null byte.
mysys/default.c:
  Make room for the trailing null bytes.
mysys/mf_pack.c:
  Make room for the trailing null byte.
server-tools/instance-manager/commands.cc:
  Copy only if overflow isn't possible in both cases.
server-tools/instance-manager/listener.cc:
  Make room for the trailing null byte.
sql/log.cc:
  Make room for the trailing null byte.
sql/sp_pcontext.h:
  Cosmetic fix.
sql/sql_acl.cc:
  MAX_HOSTNAME already specifies space for the trailing null byte.
sql/sql_parse.cc:
  Make room for the trailing null byte.
sql/sql_table.cc:
  Make room for the trailing null byte.

The test allowed random coincidence of connection ids for two concurrent
sessions performing CREATE/DROP temp tables.

Fixed with correcting the test. The sessions connection ids are not changed
from their defaults anymore.

                  
When compressed myisam files are opened, they are always memory mapped
sometimes causing memory swapping problems.

When we mmap the myisam compressed tables of size greater than the memory 
available, the kswapd0 process utilization is very high consuming 30-40% of 
the cpu. This happens only with linux kernels older than 2.6.9

With newer linux kernels, we don't have this problem of high cpu consumption
and this option may not be required.
 
The option 'myisam_mmap_size' is added to limit the amount of memory used for
memory mapping of myisam files. This option is not dynamic.

The default value on 32 bit system is 4294967295 bytes and on 64 bit system it
is 18446744073709547520 bytes.

Note: Testcase only tests the option variable. The actual bug has be to 
tested manually.

include/my_global.h:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  define SIZE_T_MAX
include/myisam.h:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  declare 'myisam_mmap_size' and 'myisam_mmap_used' variables and the mutex
  THR_LOCK_myisam_mmap
myisam/mi_packrec.c:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  add 'myisam_mmap_size' option which limits the memory available to mmap of 
  myisam files
myisam/mi_static.c:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  declare 'myisam_mmap_size' and 'myisam_mmap_used' variables and the mutex
  THR_LOCK_myisam_mmap
myisam/myisamdef.h:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  move MEMMAP_EXTRA_MARGIN to myisam.h so that it can be used in mysqld.cc
mysql-test/r/variables.result:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  Testcase for BUG#37408 to test the myisam_mmap_size option
mysql-test/t/variables.test:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  Testcase for BUG#37408 to test the myisam_mmap_size option
mysys/my_thr_init.c:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  intialize the lock THR_LOCK_myisam_mmap
sql/mysqld.cc:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  add the 'myisam_mmap_size' option
sql/set_var.cc:
  Fix for Bug #37408 - Compressed MyISAM files should not require/use mmap()
  
  add the 'myisam_mmap_size' to the SHOW VARIABLES list