revision-id inaam.rana@oracle.com-20110930110219-vnpaqghj9hm0grds
(revno 3559).

error LNK2001: unresolved external symbol _debug_sync_C_callback_ptr

OF WIDE RECORDS

row_ins_index_entry_low(), row_upd_clust_rec(): Make a redo log
checkpoint if a DEBUG flag is set. Add DEBUG_SYNC around
btr_store_big_rec_extern_fields().

rb:946 approved by Jimmy Yang

Before killing the server, tell mysql-test-run that it is to be expected.

Discussed with Bjorn Munch on IM.

              Fixed a typo in the comment.
              Fixing test cases which were previouslyno throwing  due
              disable warnings macro. 

sql/sql_base.cc:
  Change in indentation and fixing a typo in the comment.

            
During FIC error handling the trx->error_state was not being set to DB_SUCCESS
after failure, before attempting the next DDL SQL operation. This reset to
DB_SUCCESS is somewhat of a requirement though not explicitly stated anywhere.
The fix is to reset it to DB_SUCCESS in row0merge.cc if row_merge_rename_indexes
or row_merge_drop_index functions fail, also reset to DB_SUCCESS at trx commit.
				          
rb://935 Approved by Jimmy Yang.

During FIC error handling the trx->error_state was not being set to DB_SUCCESS
after failure, before attempting the next DDL SQL operation. This reset to
DB_SUCCESS is somewhat of a requirement though not explicitly stated anywhere.
The fix is to reset it to DB_SUCCESS in row0merge.cc if row_merge_rename_indexes
or row_merge_drop_index functions fail, also reset to DB_SUCCESS at trx commit.

rb://935 Approved by Jimmy Yang.

       
Problem: Statements that write to tables with auto_increment columns
         based on the selection from another table, may lead to master
         and slave going out of sync, as the order in which the rows
         are retrieved from the table may differ on master and slave.
            
Solution: We mark writing to a table with auto_increment table
          based on the rows selected from another table as unsafe. This
          will cause the execution of such statements to throw a warning
          and forces the statement to be logged in ROW if the logging
          format is mixed. 
            
Changes:
       1. All the statements that writes to a table with auto_increment 
          column(s) based on the rows fetched from another table, will now
          be unsafe.
       2. CREATE TABLE with SELECT will now be unsafe.

sql/share/errmsg-utf8.txt:
  Added new warning messages.
sql/sql_base.cc:
  -Created function to check statements that write to 
   tables with auto_increment column and has select.
  -Marked all the statements that write to a table
   with auto_increment column based on rows fetched
   from other table(s) as unsafe.
sql/sql_table.cc:
  mark CREATE TABLE[with auto_increment column] as unsafe.

      
      Problem: Statements that write to tables with auto_increment columns
      based on the selection from another table, may lead to master
      and slave going out of sync, as the order in which the rows
      are retrived from the table may differ on master and slave.
      
      Solution: We mark writing to a table with auto_increment table
      as unsafe. This will cause the execution of such statements to
      throw a warning and forces the statement to be logged in ROW if
      the logging format is mixed. 
      
      Changes: 
      1. All the statements that writes to a table with auto_increment 
      column(s) based on the rows fetched from another table, will now
      be unsafe.
      2. CREATE TABLE with SELECT will now be unsafe.


sql/share/errmsg-utf8.txt:
  Added new Warning messages
sql/sql_base.cc:
  created a new function that checks for select + write on a autoinc table
  made all such statements to be unsafe.
sql/sql_parse.cc:
  made create autoincremnet tabble + select unsafe

The actual Bug#11754376 does not exist in MySQL 5.5 because at startup
we drop entries for temporary tables from InnoDB dictionary cache (only
if ROW_FORMAT is not REDUNDANT). But nevertheless the bug in
normalize_table_name_low() is present so we fix it.

GRACEFUL SHUTDOWN

During startup mysql picks up .frm files from the tmpdir directory and
tries to drop those tables in the storage engine.

The problem is that when tmpdir ends in / then ha_innobase::delete_table()
is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it
to "/#sql123" and calls row_drop_table_for_mysql() which of course fails
to delete the table entry from the InnoDB dictionary cache.
ha_innobase::delete_table() returns an error but nevertheless mysql wipes
away the .frm file and the entry in the InnoDB dictionary cache remains
orphaned with no easy way to remove it.

The "no easy" way to remove it is to create a similar temporary table again,
copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with
tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file
after restart and will try to issue drop table for "/var/tmp/#sql123"
(notice do double slash), ha_innobase::delete_table() will normalize it to
"tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the
table entry from the dictionary cache.

The solution is to fix normalize_table_name_low() to normalize things like
"/var/tmp//table" correctly to "tmp/table".

This patch also adds a test function which invokes
normalize_table_name_low() with various inputs to make sure it works
correctly and a mtr test that calls this test function.

Reviewed by:	Marko (http://bur03.no.oracle.com/rb/r/929/)

      
rpl_heartbeat_basic test fails sporadically on pushbuild because did
not received all heartbeats from slave in circular replication.

Removed from experimental collection.

                      CORRUPTED WHEN RUN CONCURRENTLY WITH

ISSUE: Table corruption due to concurrent queries.
       Different threads running check, repair query
       along with insert. Locks not properly acquired
       in repair query. Rows are inserted inbetween
       repair query.

SOLUTION: Mutex lock is acquired before the
          repair call. Concurrent queries wont
          effect the call to repair.

                      ON 64 BIT MACHINES

PROBLEM: When sorting index during repair of
         myisam tables, due to improper casting
         of buffer size variables value of myisam_
         sort_buffer_size is not set greater than
         4GB.

SOLUTION: Proper casting of buffer size variable.
          myisam_buffer_size changed to unsigned
          long long to handle size > 4GB on
          linux as well as windows.