KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS
      
      PROBLEM:
      --------
      Consider a SP routine which does CREATE TABLE
      with REFERENCES clause. The first call to this routine
      invokes parser and the parsed items are cached, so as 
      to avoid parsing for the second execution of the routine.
      
      It is obsevered that valgrind reports a warning
      upon read of thd->lex->alter_info->key_list->Foreign_key object,
      which seem to be pointing to a invalid memory address
      during second time execution of the routine. Accessing this object
      theoretically could cause a crash.
      
      ANALYSIS:
      ---------
      The problem stems from the fact that for some reason
      elements of ref_columns list in thd->lex->alter_info->
      key_list->Foreign_key object are changed to point to
      objects allocated on runtime memory root.
      
      During the first execution of routine we create
      a copy of thd->lex->alter_info object.
      As part of this process we create a clones of objects in
      Alter_info::key_list and of Foreign_key object in particular.
      Then Foreign_key object is cloned for some reason we
      perform shallow copies of both Foreign_key::ref_columns
      and Foreign_key::columns list. So new instance of 
      Foreign_key object starts to SHARE contents of ref_columns
      and columns list with the original instance.
      After that as part of cloning process we call
      list_copy_and_replace_each_value() for elements of
      ref_columns list. As result ref_columns lists in both
      original and cloned Foreign_key object start to contain
      pointers to Key_part_spec objects allocated on runtime
      memory root because of shallow copy.
      
      So when we start copying of thd->lex->alter_info object
      during the second execution of stored routine we indeed
      encounter pointer to the Key_part_spec object allocated
      on runtime mem-root which was cleared during at the end
      of previous execution. This is done in sp_head::execute(), 
      by a call to free_root(&execute_mem_root,MYF(0));
      As result we get valgrind warnings about accessing 
      unreferenced memory.
      
      FIX:
      ----
      The safest solution to this problem is to 
      fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do
      a deep copy of columns lists, similar to Key(Key, MEM_ROOT) 
      constructor.

Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP

The assert in 13580775 is visible in 5.6 only, 
but shows that all versions are vulnerable.
13011410 crashes in all versions.

filesort tries to re-use the sort buffer between invocations in order to save
malloc/free overhead.
The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT.
added an assert that buffer properties (num_records, record_length) are
consistent between invocations. Indeed, they are not necessarily consistent.
  
Fix: re-allocate the sort buffer if properties change.


mysql-test/r/partition.result:
  New tests.
mysql-test/t/partition.test:
  New tests.
sql/filesort.cc:
  If we already have allocated a sort buffer in a previous execution,
  then verify that it is big enough for the current one.
sql/table.h:
  Add sort_keys_size; Number of bytes allocated for the sort_keys buffer.

                     routines.

mysqldump in xml mode did not dump routines, events or
triggers.

This patch fixes this issue by fixing the if conditions
that disallowed the dump of above mentioned objects in
xml mode, and added the required code to enable dump
in xml format.


client/mysqldump.c:
  BUG#11760384 - 52792: mysqldump in XML mode does not dump
                        routines.
  
  Fixed some if conditions to allow execution of dump methods
  for xml and further added the relevant code at places to produce
  the dump in xml format.
mysql-test/r/mysqldump.result:
  Added a test case for Bug#11760384.
mysql-test/t/mysqldump.test:
  Added a test case for Bug#11760384.

If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling.

rb:875 approved by Jimmy Yang

------------------------------------------------------------
revno: 3258
committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
branch nick: mysql-trunk-bug12663165
timestamp: Thu 2011-07-14 10:05:12 +0200
message:
  Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS
  
  When stored routines are loaded, a simple optimizer tries to locate
  and remove dead code. The problem was that this dead code removal
  did not work correctly with CONTINUE handlers.
  
  If a statement triggers a CONTINUE handler, the following statement
  will be executed after the handler statement has completed. This
  means that the following statement is not dead code even if the
  previous statement unconditionally alters control flow. This fact
  was lost on the dead code removal routine, which ended up with
  removing instructions that could have been executed. This could
  then lead to assertions, crashes and generally bad behavior when
  the stored routine was executed.
  
  This patch fixes the problem by marking as live code all stored
  routine instructions that are in the same scope as a CONTINUE handler.
  
  Test case added to sp.test.

Fixed it to work with "--repeat" option.

Fixed the testcase using timestamp logic while doing grep from the error file.

If init_command was incorrect, we couldn't let users execute
queries, but we couldn't report the issue to the client either
as it does not expect error messages before even sending a
command. Thus, we simply disconnected them without throwing
a clear error.

We now go through the proper sequence once (without executing
any user statements) so we can report back what the problem
is. Only then do we disconnect the user.

As always, root remains unaffected by this as init_command is
(still) not executed for them.

mysql-test/r/init_connect.result:
  We now report a proper error if init_command fails.
  Expect as much.
mysql-test/t/init_connect.test:
  We now report a proper error if init_command fails.
  Expect as much.
sql/sql_connect.cc:
  If init_command fails, throw an error explaining this to
  the user.

InnoDB: Remove HAVE_purify, UNIV_INIT_MEM_TO_ZERO, UNIV_SET_MEM_TO_ZERO.

The compile-time setting HAVE_purify can mask potential bugs.
It is being set in PB2 Valgrind runs. We should simply get rid of it,
and replace it with UNIV_MEM_INVALID() to declare uninitialized memory
as such in Valgrind-instrumented binaries.

os_mem_alloc_large(), ut_malloc_low(): Remove the parameter set_to_zero.

ut_malloc(): Define as a macro that invokes ut_malloc_low().

buf_pool_init(): Never initialize the buffer pool frames. All pages
must be initialized before flushing them to disk.

mem_heap_alloc(): Never initialize the allocated memory block.

os_mem_alloc_nocache(), ut_test_malloc(): Unused function, remove.

rb:813 approved by Jimmy Yang

COMMUNICATION PACKETS, ERROR_CODE: 1160

Addendum: for some queries table->in_use might be NULL -
check it.

COMMUNICATION PACKETS, ERROR_CODE: 1160

If idle FEDERATED table is evicted from the table cache when 
a connection to remote server is lost, query that initiated 
eviction may fail.
If this query is executed by slave SQL thread it may fail as well.

An error of close was stored in diagnostics area, which was later
attributed to the statement that caused eviction.

With this patch FEDERATED clears an error of close.

CREATE TABLE bug13510739 (c INTEGER NOT NULL, PRIMARY KEY (c)) ENGINE=INNODB;
INSERT INTO bug13510739 VALUES (1), (2), (3), (4);
DELETE FROM bug13510739 WHERE c=2;
HANDLER bug13510739 OPEN;
HANDLER bug13510739 READ `primary` = (2);
HANDLER bug13510739 READ `primary` NEXT;  <-- crash

The bug is that in the particular testcase row_search_for_mysql() picked up
a delete-marked record and quit, leaving the cursor non-positioned state and
on the subsequent 'get next' call the code crashed because of the
non-positioned cursor.

In row0sel.cc (line numbers from mysql-trunk):

4653         if (rec_get_deleted_flag(rec, comp)) {
...
4679                 if (index == clust_index && unique_search) {
4680 
4681                         err = DB_RECORD_NOT_FOUND;
4682                         
4683                         goto normal_return;
4684                 }       

it quit from here, not storing the cursor position.

In contrast, if the record=2 is not found at all (e.g. sleep(1) after DELETE
to let the purge wipe it away completely) then 'get = 2' does find record=3
and quits from here:

4366                 if (0 != cmp_dtuple_rec(search_tuple, rec, offsets)) {
...
4394                         btr_pcur_store_position(pcur, &mtr);
4395 
4396                         err = DB_RECORD_NOT_FOUND;
4397 #if 0
4398                         ut_print_name(stderr, trx, FALSE, index->name);
4399                         fputs(" record not found 3\n", stderr);
4400 #endif
4401 
4402                         goto normal_return;

Another fix could be to extend the condition on line 4366 to hold only if
seach_tuple matches rec AND if rec is not delete marked.

Notice that in the above test case if we wait about 1 second somewhere after
DELETE and before 'get = 2', then the testcase does not crash and returns 4
instead. Not sure if this is the correct behavior, but this bugfix removes
the crash and makes the code return what it also returns in the non-crashing
case (if rec=2 is not found during 'get = 2', e.g. we have sleep(1) there).

Approved by:	Marko (http://bur03.no.oracle.com/rb/r/863/)

rb://865
approved by: Jimmy

Integer overflow causes division by zero.

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.

SMALL KEY CACHE

The server crashed on division by zero because the key cache was not
initialized and the block length was 0 which was used in a division.

The fix was to not allow CACHE INDEX if the key cache was not initiallized.
Thus never try LOAD INDEX INTO CACHE for an uninitialized key cache.

Also added some windows files/directories to .bzrignore.

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