discarded in buf_page_create()

This bug turned out to be a false alarm, a bug in the UNIV_SYNC_DEBUG
diagnostic code. Because of this, the patch was not backported to the
built-in InnoDB in MySQL 5.1. Furthermore, there is no test case for
InnoDB Plugin in MySQL 5.1, because the delete buffering in MySQL 5.5
makes triggering the failure much easier.

When a freed page for which there exist orphaned buffered changes is
allocated and reused for something else, buf_page_create() will discard
the buffered changes by invoking ibuf_merge_or_delete_for_page().
This would violate the InnoDB latching order.

Tweak the latching order as follows. Move SYNC_IBUF_MUTEX below
SYNC_FSP_PAGE, where it logically belongs, and assign new latching
levels for the ibuf->index->lock and the insert buffer B-tree pages:

#define SYNC_IBUF_MUTEX		370	/* ibuf_mutex */
#define SYNC_IBUF_INDEX_TREE	360
#define SYNC_IBUF_TREE_NODE_NEW	359
#define SYNC_IBUF_TREE_NODE	358

btr_block_get(), btr_page_get(): In UNIV_SYNC_DEBUG, add the parameter
"index" for determining the appropriate latching order
(SYNC_IBUF_TREE_NODE or SYNC_TREE_NODE).

btr_page_alloc_for_ibuf(), btr_create(): Use SYNC_IBUF_TREE_NODE_NEW
instead of SYNC_TREE_NODE_NEW for insert buffer pages.

btr_cur_search_to_nth_level(), btr_pcur_restore_position_func(): Use
SYNC_IBUF_TREE_NODE instead of SYNC_TREE_NODE for insert buffer pages.

btr_search_guess_on_hash(): Assert that the index is not an insert buffer tree.

dict_index_add_to_cache(): Use SYNC_IBUF_INDEX_TREE for the insert
buffer tree (ibuf->index->lock).

ibuf0ibuf.c: Use SYNC_IBUF_TREE_NODE or SYNC_IBUF_TREE_NODE_NEW for
all B-tree pages.

ibuf_merge_or_delete_for_page(): Assert that the user page is
BUF_IO_READ fixed. Only in this way it is OK to latch it as
SYNC_IBUF_TREE_NODE instead of the proper SYNC_TREE_NODE (which would
violate the changed latching order).

sync_thread_add_level(): Remove the special tweak for
SYNC_IBUF_MUTEX. Add rules for the added latching levels.

rb:591 approved by Jimmy Yang

row_sel_field_store_in_mysql_format(): Do not pad the unused part of
the buffer reserved for a True VARCHAR column (introduced in 5.0.3).
Add Valgrind instrumentation ensuring that the unused part will be
flagged uninitialized.

row_sel_copy_cached_field_for_mysql(): New function: Copy a field
that is in the MySQL row format, not copying the unused tail of
VARCHAR columns.

row_sel_pop_cached_row_for_mysql(): Invoke
row_sel_copy_cached_field_for_mysql() for copying fields.
When the row is long, copy it field-by-field.

rb:715 approved by Inaam Rana

for compressed InnoDB tables

ha_innodb::info_low(): For calculating data_length or index_length,
use the compressed page size for compressed tables instead of UNIV_PAGE_SIZE.

rb:714 approved by Sunny Bains

There is an optimization of DISTINCT in JOIN::optimize()
which depends on THD::used_tables value. Each SELECT statement
inside SP resets used_tables value(see mysql_select()) and it
leads to wrong result. The fix is to replace THD::used_tables
with LEX::used_tables.


mysql-test/r/sp.result:
  test case
mysql-test/t/sp.test:
  test case
sql/sql_base.cc:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_class.cc:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_class.h:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_insert.cc:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_lex.cc:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_lex.h:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_prepare.cc:
  THD::used_tables is replaced with LEX::used_tables
sql/sql_select.cc:
  THD::used_tables is replaced with LEX::used_tables

The problem is that TIME_FUZZY_DATE is explicitly used for get_arg0_date()
function in Item_date_typecast::get_date method. The fix is to use real
fuzzy_date value.


mysql-test/r/func_time.result:
  test case
mysql-test/t/func_time.test:
  test case
sql/item_timefunc.cc:
  use real fuzzy_date value

TOOLS

Backport a fix for Bug 57094 from 5.5.
The following revision was backported:

# revision-id: alexander.nozdrin@oracle.com-20101006150613-ls60rb2tq5dpyb5c
# parent: bar@mysql.com-20101006121559-am1e05ykeicwnx48
# committer: Alexander Nozdrin <alexander.nozdrin@oracle.com>
# branch nick: mysql-5.5-bugteam-bug57094
# timestamp: Wed 2010-10-06 19:06:13 +0400
# message:
#   Fix for Bug 57094 (Copyright notice incorrect?).
#   
#   The fix is to:
#     - introduce ORACLE_WELCOME_COPYRIGHT_NOTICE define to have a single place
#       to specify copyright notice;
#     - replace custom copyright notices with ORACLE_WELCOME_COPYRIGHT_NOTICE
#       in programs.

The title of the bug is a little confusing. The actual fix is to
reintroduce random readahead inside InnoDB with a dynamic, global
switch innodb_random_read_ahead [default = off].

Approved by: Sunny Bains
rb://696

Original changeset:
revision-id: alexander.nozdrin@oracle.com-20101221122349-6h8ammcro70a4pac
parent: sven.sandberg@oracle.com-20101221121948-hnivuulyohzch1v4
committer: Alexander Nozdrin <alexander.nozdrin@oracle.com>
branch nick: mysql-trunk-bugfixing
timestamp: Tue 2010-12-21 15:23:49 +0300
message:
  A patch for Bug#59060 (Valgrind warning in Protocol_text::store()).
  
  We should not assume to have zero-terminated strings.

HA_ERR was returning 0 (null string) when no error happened 
(error=0). Since HA_ERR is used in DBUG_PRINT, regardless there 
was an error or not, the server could crash in solaris debug
builds.

We fix this by:

  - deploying an assertion that ensures that the function 
    is not called when no error has happened;
  - making sure that HA_ERR is only called when an error 
    happened;
  - making HA_ERR return "No Error", instead of 0, for 
    non-debug builds if it is called when no error happened.

This will make HA_ERR return values to work with DBUG_PRINT on
solaris debug builds.

                  
The server crashes if it processes table map events that are
corrupted, especially if they map different tables to the same
identifier. This could happen, for instance, due to BUG 56226.
                  
We fix this by checking whether the table map has already been
mapped before actually applying the event. If it has been mapped
with different settings an error is raised and the slave SQL
thread stops. If it has been mapped with same settings the event
is skipped. If the table is set to be ignored by the filtering
rules, there is no change in behavior: the event is skipped and
ids are not checked.


mysql-test/suite/rpl/t/rpl_row_corruption.test:
  Added a simple test case that checks both cases:
  - multiple table maps with the same identifier
  - multiple table maps with the same identifier, but only one
    is processed (the others are filtered out)

When CREATE TABLE wasn't given ENGINE=... it would determine
the default ENGINE at parse-time rather than at execution
time, leading to incorrect behaviour (namely, later changes
to the default engine being ignore) when calling CREATE TABLE
from a stored procedure.

We now defer working out the default engine till execution of
CREATE TABLE.


mysql-test/r/sp_trans.result:
  results!
mysql-test/t/sp_trans.test:
  Show that CREATE TABLE (called from store routine) heeds
  any changes after CREATE SP / parse-time. Show that explicitly
  requesting an ENGINE still works.
sql/sql_parse.cc:
  If no ENGINE=... was given at parse-time, determine default
  engine at execution time of CREATE TABLE.
sql/sql_yacc.yy:
  If CREATE TABLE is not given ENGINE=..., don't bother
  figuring out the default engine during parsing; we'll
  do it at execution time instead to be aware of the
  latest updates.

Manually merged from mysql-5.0 into mysql-5.1.

conflicts
=========

include/Makefile.am

Follow-up patch that adds the newly added header file to
Makefile.am noinst_HEADERS.

Manually merged mysql-5.0 into mysql-5.1.

conflicts
=========
client/mysqlibinlog.cc

CLIENT TOOLS
      
The fix is to backport part of revision:
        
  - alexander.nozdrin@oracle.com-20101006150613-ls60rb2tq5dpyb5c
      
from mysql-5.5. In detail, we add the oracle welcome notice
header file proposed in the original patch and include/use it
in client/mysqlbinlog.cc, replacing the existing and obsolete
notice.

bug.  It added this assert;
    ut_ad(ind_field->prefix_len);
before a section of code that assumes there is a prefix_len.  

The patch replaced code that explicitly avoided this with a check for
prefix_len.  It turns out that the purge thread can get to that assert
without a prefix_len because it does not use a row_ext_t* .
When UNIV_DEBUG is not defined, the affect of this is that the purge thread
sets the dfield->len to zero and then cannot find the entry in the index to
purge.  So secondary index entries remain unpurged.

This patch does not do the assert.  Instead, it uses
    'if (ind_field->prefix_len) {...}'
around the section of code that assumes a prefix_len.  This is the way the
patch I provided to Marko did it.

The test case is simply modified to do a sleep(10) in order to give the
purge thread a chance to run. Without the code change to row0row.c, this
modified testcase will assert if InnoDB was compiled with UNIV_DEBUG.
I tried to sleep(5), but it did not always assert.

Let the creation of the "test" database happen only during a new
installation, not in an RPM upgrade.

Added a conditional echo at end of configure.in