"freeing items"

The calculation of the table map log event in the event constructor
was one byte shorter than what would be actually written. This would
lead to a mismatch between the number of bytes written and the event
end_log_pos, causing bad event alignment in the binlog (corrupted
binlog) or in the transaction cache while fixing positions
(MYSQL_BIN_LOG::write_cache). This could lead to impossible to read
binlog or even infinite loops in MYSQL_BIN_LOG::write_cache.

This patch addresses this issue by correcting the expected event
length in the Table_map_log_event constructor, when the field metadata
size exceeds 255.

sql/log_event.cc:
  Added the extra byte as net_store_length imposes.

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


mysql-test/r/heap_btree.result:
  Updated test result after adding new test for this bug.
mysql-test/t/heap_btree.test:
  Updated test result after adding new test for the bug report.
sql/sql_delete.cc:
  Updated to check if the files in delete list appears in join list and disable 
  delete while scanning, if it appears.

When a user selected an unsupported character set for an
IBMDB2I table, error 2501 or 2511 may have been returned,
giving the appearance of an internal programming error.

This patch consolidates these errors into a single descriptive
error message for the common case of an unsupported character
set.

The new error number is 2504 and indicates a user error.
The errors 2501 and 2511 remain to indicate cases of internal
programming errors.

storage/ibmdb2i/db2i_charsetSupport.cc:
  Bug#44232 Error msg should be improved when collation not supported.
          
  consolidate errors 2501 and 2511 into a single
  descriptive error message for the common case
  of an unsupported character set.
storage/ibmdb2i/db2i_conversion.cc:
  Bug#44232 Error msg should be improved when collation not supported.
          
  consolidate errors 2501 and 2511 into a single
  descriptive error message for the common case
  of an unsupported character set.
storage/ibmdb2i/db2i_errors.cc:
  Bug#44232 Error msg should be improved when collation not supported.
          
  consolidate errors 2501 and 2511 into a single
  descriptive error message for the common case
  of an unsupported character set.
storage/ibmdb2i/db2i_errors.h:
  Bug#44232 Error msg should be improved when collation not supported.
          
  consolidate errors 2501 and 2511 into a single
  descriptive error message for the common case
  of an unsupported character set.

on cp932 and sjis environment.
Problem: case conversion erroneously changes the second bytes
of multi-byte sequences because single-byte functions were
called in a mistake.
Fix: call multi-byte aware functions instead.

removed few sprintf's

'INSERT ... SELECT' statements

Merge

'INSERT ... SELECT' statements
            
The code that produces result rows expected that a duplicate row
error could not occur in INSERT ... SELECT statements with 
unfulfilled WHERE conditions. This may happen, however, if the 
SELECT list contains only aggregate functions.
Fixed by checking if an error occured before trying to send EOF
to the client.


mysql-test/r/insert_select.result:
  Bug#44306: Test result
mysql-test/t/insert_select.test:
  Bug#44306: Test case
sql/sql_select.cc:
  Bug#44306: Fix

A backport of fix for "BUG40092 - Storage engine API uses
time_t datatype".

Starting from MSVC C++ 2005 (v8), the default size of time_t
is changed from 32-bit to 64-bit. As the result, the binaries
built with pre-v8 MSVC C++ do not work with the binaries
(storage engine plugins) built with v8 or after (server
crashes).

Fixed storage engine API to use datatype with known size
(ulong) instead of time_t.

sql/handler.h:
  Bug#39802 On Windows, 32-bit time_t should be enforced
  
  Change create_time, check_time, update_time
  in the ha_statistics and PARTITION_INFO
  structures to ulong.

1. Replace waiting of SQL thread stop by waiting of SQL error on slave and stopped
SQL thread.
2. Remove debug code because it already implemented in MTR2.

EXPLAIN EXTENDED of nested query containing a error:

   1054 Unknown column '...' in 'field list'

may cause a server crash.


Parse error like described above forces a call to
JOIN::destroy() on malformed subquery.
That JOIN::destroy function closes and frees temporary
tables. However, temporary fields of these tables
may be listed in st_select_lex::group_list of outer
query, and that st_select_lex may not cleanup them
properly. So, after the JOIN::destroy call that
st_select_lex::group_list may have Item_field
objects with dangling pointers to freed temporary
table Field objects. That caused a crash.


mysql-test/r/subselect3.result:
  Added test case for bug #37362.
mysql-test/t/subselect3.test:
  Added test case for bug #37362.
sql/sql_select.cc:
  Bug #37362: Crash in do_field_eq
  
  The JOIN::destroy function has been modified to
  cleanup temporary table column items.

This patch adds corrections to the original patch
submitted 2009-04-08 (http://lists.mysql.com/commits/71607):

- fixed that the original patch didn't work because of an
  incorrect condition;
- added a test case.

mysql-test/r/upgrade.result:
  Bug#37631 Incorrect key file for table after upgrading from 5.0 to 5.1
  
  Result file for test case
mysql-test/std_data/bug37631.MYD:
  Bug#37631 Incorrect key file for table after upgrading from 5.0 to 5.1
  
  table created in mysql 4.0
mysql-test/std_data/bug37631.MYI:
  Bug#37631 Incorrect key file for table after upgrading from 5.0 to 5.1
  
  table created in mysql 4.0
mysql-test/std_data/bug37631.frm:
  Bug#37631 Incorrect key file for table after upgrading from 5.0 to 5.1
  
  table created in mysql 4.0
mysql-test/t/upgrade.test:
  Bug#37631 Incorrect key file for table after upgrading from 5.0 to 5.1
  
  Adds test for checking that upgrade works
  on a table which is created by a mysql
  server version <= 4.0.
storage/myisam/ha_myisam.cc:
  Bug#37631 Incorrect key file for table after upgrading from 5.0 to 5.1
  
  Fix the conformance checker to relax checking
  for the correct version of the tables (for tables
  created by mysql server version <= 4.0)

my_error() was invoked in reset_slave()'s with purge_relay_logs()-failing branch
without passing sql_errno to it.

Fixed with setting sql_errno= ER_RELAY_LOG_FAIL in the purge_relay_logs()-failing branch.




sql/sql_repl.cc:
  set sql_errno= ER_RELAY_LOG_FAIL when purge_relay_logs() fails.

into actual tree

                                    table corruption


Moved the testcase from the file myisam.test to the new testfile 
mysiam_debug.test
 

mysql-test/r/myisam.result:
  Removed result file for BUG#40827
mysql-test/r/myisam_debug.result:
  Result file for BUG#40827
mysql-test/t/myisam.test:
  Removed testcase for BUG#40827
mysql-test/t/myisam_debug.test:
  TestCase for BUG#40827

This is a "null" merge because the fix is
already in 5.1

Error happens because sp_head::MULTI_RESULTS is not set for SP
which has 'show table status' command.
The fix is to add a SQLCOM_SHOW_TABLE_STATUS case into
sp_get_flags_for_command() func.


mysql-test/r/sp.result:
  test result
mysql-test/t/sp.test:
  test case
sql/sp_head.cc:
  Error happens because sp_head::MULTI_RESULTS is not set for SP
  which has 'show table status' command.
  The fix is to add a SQLCOM_SHOW_TABLE_STATUS case into
  sp_get_flags_for_command() func.

per-file comments:
  tests/mysql_client_test.c
the test for bug 37956 isn't relevant anymore.
The query there 'select point(?,?)' doesn't produce an error.

                       
Killing the insert-select statement corrupts the MyISAM table only
when the destination table is empty and when it has indexes. When 
we bulk insert huge data and if the destination table is empty we 
disable the indexes for fast inserts, data is then inserted and 
indexes are re-enabled after bulk_insert operation
                        
Killing the query, aborts the repair table operation during enable
indexes phase leading to table corruption.
                      
We now truncate the table when we detect that enable indexes is
killed for bulk insert query.As we have an empty table before the 
operation, we can fix by truncating the table.

mysql-test/r/myisam.result:
  Result file for BUG#40827
mysql-test/t/myisam.test:
  Testcase for BUG#40827
storage/myisam/ha_myisam.cc:
  Fixed end_bulk_insert() method to truncate the table when we detect enable 
  index operation is killed.