The counter handler_read_key (SSV::ha_read_key_count) is incremented 
incorrectly.

The mysql server maintains a per thread system_status_var (SSV)
object.  This object contains among other things the counter
SSV::ha_read_key_count. The purpose of this counter is to measure the
number of requests to read a row based on a key (or the number of
index lookups).

This counter was wrongly incremented in the
ha_innobase::innobase_get_index(). The fix removes
this increment statement (for both innodb and innodb_plugin).

The various callers of the innobase_get_index() was checked to
determine if anybody must increment this counter (if they first call
innobase_get_index() and then perform an index lookup).  It was found
that no caller of innobase_get_index() needs to worry about the
SSV::ha_read_key_count counter.

When printing information about a ROW_FORMAT=REDUNDANT record, pass
the correct flag to rec_get_next_offs().

rb:821 approved by Jimmy Yang

Post-push fix: build break on windows/optimized

handle_segfault is the signal handler code of mysqld.  however, it makes
calls to potentially unsafe functions localtime_r, fprintf, fflush.



include/my_stacktrace.h:
  Add safe versions of itoa() write() and snprintf().
libmysqld/CMakeLists.txt:
  Move signal handler to separate file.
mysys/stacktrace.c:
  Remove unsafe function calls.
sql/CMakeLists.txt:
  Move signal handler to separate file.
sql/Makefile.am:
  Move signal handler to separate file.
sql/mysqld.cc:
  Move signal handler to separate file.
sql/signal_handler.cc:
  Remove unsafe function calls.

readline.cc: In function char* batch_readline(LINE_BUFFER*):
readline.cc:60:9: error: out_length may be used uninitialized in this function
log.cc: In function int find_uniq_filename(char*):
log.cc:1857:8: error: number may be used uninitialized in this function

                    WITH MYISAM_USE_MMAP ENABLED

MySQL server can crash due to segmentation fault when
started with myisam_use_mmap.

The reason behind this being, while making a request to
unmap (munmap) the previously mapped memory (mmap), the
size passed was 7 bytes larger than the size requested at
the time of mapping. This can eventually unmap the adjacent
memory mapped block, belonging to some other memory-map pool.
Hence the subsequent call to mmap can map a region which was
still a valid memory mapped area.

Fixed by removing the extra 7-byte margin which was erroneously
added to the size, used for unmappping.


storage/myisam/mi_close.c:
  Bug#11756764 48726: MYSQLD KEEPS CRASHING WITH SIGSEGV
                      WITH MYISAM_USE_MMAP ENABLED
  
  Added a condition to call _mi_unmap_file() in case
  of compressed records. mi_munmap_file() is called
  otherwise.
storage/myisam/mi_packrec.c:
  Bug#11756764 48726: MYSQLD KEEPS CRASHING WITH SIGSEGV
                      WITH MYISAM_USE_MMAP ENABLED
  
  mi_dynmap_file() function, after successfully executing
  mmap, stores the total size in info->s->mapped_length
  variable. Now, if mi_dynmap_file() is invoked with a size
  with an extra 7-byte margin (MEMMAP_EXTRA_MARGIN),
  the margin will eventually also get stored in mapped_length.
  So, un-mapping function can simply use the value stored in
  mapped_length in order to unmap the previously mapped
  region.

                      AND HANG IN SHOW TABLE STATUS.

ISSUE: Table corruption due to concurrent queries.
       Different threads running insert and check
       query leads to table corruption. Not properly locked,
       rows are inserted in between check query.

SOLUTION: In check query mutex lock is acquired
          for a longer time to handle concurrent
          insert and check query.

NOTE: Additionally we backported the fix for CHECKSUM
      issue(bug#11758979).

sporadically on 5.1. See Bug#12584161.

Test runs successfully on 5.5/trunk, so this changeset will
be null-merged.

  
rb://816
approved by: Marko Makela
  
The title is misleading. This bug was actually introduced by
bug 12635227 and was unearthed by a later optimization.
We need to free buf_page_t structs that we are allocating using
malloc() at shutdown.

The bug was accidentally fixed by fixing
Bug#11759688 52020: InnoDB can still deadlock on just INSERT...ON DUPLICATE KEY
a.k.a. the reintroduction of
Bug#7975 deadlock without any locking, simple select and update

a.k.a. Bug#7975 deadlock without any locking, simple select and update

Bug#7975 was reintroduced when the storage engine API was made
pluggable in MySQL 5.1. Instead of looking at thd->lex directly, we
rely on handler::extra(). But, we were looking at the wrong extra()
flag, and we were ignoring the TRX_DUP_REPLACE flag in places where we
should obey it.

innodb_replace.test: Add tests for hopefully all affected statement
types, so that bug should never ever resurface. This kind of tests
should have been added when fixing Bug#7975 in MySQL 5.0.3 in the
first place.

rb:806 approved by Sunny Bains

btr_pcur_restore_position_func(): When the cursor was positioned at
the tree infimum or supremum, initialize pos_state and latch_mode. The
assertion failed, because pos_state was BTR_PCUR_WAS_POSITIONED.  In
the test failure of WL#5874, the purge thread attempted to restore the
cursor position on the infimum record (the clustered index was empty).

btr_pcur_detach(), btr_pcur_is_detached(): Unused functions, remove.

rb:804 approved by Inaam Rana

In all callers of row_sel_convert_mysql_key_to_innobase(), assert
that the converted key is empty or nonempty when it should be.

Also fixed possibly uninitialized use of need_copy_table_res.

row_rename_table_for_mysql(): Return DB_ERROR instead of DB_SUCCESS
when fil_rename_tablespace() returns an error. This bug was introduced
in the InnoDB Plugin.

Approved by Sunny Bains over IM.

Bug#12612184 RACE CONDITION AFTER BTR_CUR_PESSIMISTIC_UPDATE()

The fix introduced potentially more severe crash recovery problems
than the bug causes. Revert the fix for now.

This was an attempt to address problems with the Bug#12612184 fix.
Even with this follow-up fix, crash recovery can be broken.
Let us fix the bug later.

In the ON UPDATE CASCADE clause of FOREIGN KEY constraints, the
calculated update vector was not fully initialized. This bug was
introduced in the InnoDB Plugin when implementing support for
ROW_FORMAT=DYNAMIC.

Additionally, the data type information was not initialized, but
apparently it has never been needed in this case.  Nevertheless, it is
not good programming practice to pass uninitialized values around.

calc_row_difference(): Declare the update field uninitialized in
Valgrind. Copy the data type information as well, except when the
field is SQL NULL. In the built-in InnoDB, initialize
ufield->extern_storage = FALSE (an initialization bug that had gone
unnoticed this far). The InnoDB Plugin and later have this flag to
dfield_t and have always initialized it properly.

row_ins_cascade_calc_update_vec(): Reduce the scope of some
pointers. Initialize orig_len. (This caused the bug in InnoDB Plugin
and later.)

row_ins_foreign_check_on_constraint(): Simplify a condition. Declare
the update vector uninitialized.

rb:771 approved by Jimmy Yang

PARENT FOR OTHER ONE

Do not try to lookup key_nr'th key in 'table' because there may not be such
a key there. key_nr is the number of the key in the _child_ table name, not
in the parent table.

Instead just print the fields of the record that are covered by the first key
defined on the parent table.

This bug gets a better fix in MySQL 5.6, which is too risky for 5.1 and 5.5.

Approved by:	Jon Olav Hauglid (via IM)

Fixed a misplaced parenthesis, injected due to
syncing from libedit CVS head.

             BREAKS SOURCE RELEASE BUILD

Some of the required files were not getting copied while
performing 'make dist' and hence the build failed for
the created distribution source.

Added the missing files to Makefile.am.

btr_record_not_null_field_in_rec(): Remove the parameter rec.
Use rec_offs_nth_sql_null() instead of rec_get_nth_field().

rb:788 approved by Jimmy Yang

               USING MYISAM_USE_MMAP ON WINDOWS

When OPTIMIZE/REPAIR TABLE is switching to new data file,
old data file is removed while memory mapping is still
active.

With 5.1 implementation of nt_share_delete() it is not
permitted to remove mmaped file.

This fix disables memory mapping for mi_repair() operations.

mysql-test/r/myisam.result:
  A test case for BUG#11757032.
mysql-test/t/myisam.test:
  A test case for BUG#11757032.
storage/myisam/ha_myisam.cc:
  mi_repair*() functions family use file I/O even if memory
  mapping is available.
  
  Since mixing mmap I/O and file I/O may cause various artifacts,
  memory mapping must be disabled.
storage/myisam/mi_delete_all.c:
  Clean-up: do not attempt to remap file after truncate, since
  there is nothing to map.

sql/sp_head.cc:
  alignment-safe copy
sql/sql_cache.cc:
  alignment-safe copy
sql/sql_parse.cc:
  alignment-safe copy