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)

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

Update copyright comment in innochecksum.

Refactor the !rec_offs_any_extern relaxation in row_build().

trx_assert_active(trx_id): Assert that the given transaction is active.
(In the 5.1 built-in InnoDB, there is no trx->is_recovered field.)

trx_assert_recovered(trx_id): Assert that the given transaction is
active and has been recovered after a crash.

row_build(): Replace a bunch of code with an assertion that invokes
trx_assert_active() or trx_assert_recovered() and row_get_rec_trx_id().

row_get_trx_id_offset(): Make the function inlined. Remove the unused
parameter rec, and make all parameters const.

row_get_rec_trx_id(), row_get_rec_roll_ptr(): Make all parameters const.

rb:691 approved by Jimmy Yang

page_zip_dir_elems(): New function, refactored from page_zip_dir_size().

page_zip_dir_size(): Use page_zip_dir_elems()

page_zip_dir_start_offs(): New function: Gets an offset to the
compressed page trailer (the dense page directory), including deleted
records (the free list)

page_zip_dir_start_low(page_zip, n_dense): Constness-preserving
wrapper macro for page_zip_dir_start_offs().

page_zip_dir_start(page_zip): Constness-preserving
wrapper macro for page_zip_dir_start_offs().

page_zip_decompress_node_ptrs(), page_zip_decompress_clust(): Replace
a formula with a fully equivalent page_zip_dir_start_low() call.

page_zip_write_rec(), page_zip_parse_write_node_ptr(),
page_zip_write_node_ptr(), page_zip_write_trx_id_and_roll_ptr(),
page_zip_clear_rec(): Replace a formula with an almost equivalent
page_zip_dir_start() call.
It is OK to replace page_dir_get_n_heap(page) with
page_dir_get_n_heap(page_zip->data), because
ut_ad(page_zip_header_cmp(page_zip, page)) or
page_zip_validate(page_zip, page) asserts that the
page headers are identical.

rb:687 approved by Jimmy Yang

BOGUS "THE TABLE MYSQL.PROC IS MISSING,..."

There was a race condition between loading a stored routine
(function/procedure/trigger) specified by fully qualified name
SCHEMA_NAME.PROC_NAME and dropping the stored routine database.

The problem was that there is a window for race condition when one server
thread tries to load a stored routine being executed and the other thread
tries to drop the stored routine schema.

This condition race window exists in implementation of function
mysql_change_db() called by db_load_routine() during loading of stored
routine to cache. Function mysql_change_db() calls check_db_dir_existence()
that might failed because specified database was dropped during concurrent
execution of DROP SCHEMA statement. db_load_routine() calls mysql_change_db()
with flag 'force_switch' set to 'true' value so when referenced db is not found
then my_error() is not called and function mysql_change_db() returns ok.
This shadows information about schema opening error in db_load_routine().
Then db_load_routine() makes attempt to parse stored routine that is failed.
This makes to return error to sp_cache_routines_and_add_tables_aux() but since
during error generation a call to my_error wasn't made and hence
THD::main_da wasn't set we set the generic "mysql.proc table corrupt" error
when running sp_cache_routines_and_add_tables_aux().

The fix is to install an error handler inside db_load_routine() for
the mysql_op_change_db() call, and check later if the ER_BAD_DB_ERROR
was caught.


sql/sql_db.cc:
  Added synchronization point "before_db_dir_check" to emulate a race condition during
  processing of CALL/DROP SCHEMA.

approved by: Marko
rb://681

Coalescing of free buf_page_t descriptors can prove to be one severe
bottleneck in performance of compression. One such workload where it
hurts badly is DROP TABLE. This patch removes buf_page_t allocations
from buf_buddy and uses ut_malloc instead.
In order to further reduce overhead of colaescing we no longer attempt
to coalesce a block if the corresponding free_list is less than 16 in
size.

This patch fixes a typo in a YaSSL error message.

TO POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
 
ALTER TABLE MODIFY/CHANGE ... FIRST did nothing except renaming
columns if new version of the table had exactly the same 
structure as the old one (i.e. as result of such statement, names 
of columns changed their order as specified but data in columns 
didn't). The same thing happened for ALTER TABLE DROP COLUMN/ADD 
COLUMN statements which were supposed to produce new version of
table with exactly the same structure as the old version of table.
I.e. in the latter case the result was the same as if old column 
was renamed instead of being dropped and new column with default
as value being created.
 
Both these problems were caused by the fact that ALTER TABLE
implementation incorrectly interpreted both these situations as 
simple renaming of columns and assumed that in-place ALTER TABLE
algorithm could have been used for them.
 
This patch fixes this problem by ensuring that in cases when some
column is moved to the first position or some column is dropped
the default ALTER TABLE algorithm involving table copying is 
always used. This is achieved by detecting such situations in
mysql_prepare_alter_table() and setting Alter_info::change_level
to ALTER_TABLE_DATA_CHANGED for them.

mysql-test/r/alter_table.result:
  Added test for bug #12652385 - "61493: REORDERING COLUMNS TO
  POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
mysql-test/t/alter_table.test:
  Added test for bug #12652385 - "61493: REORDERING COLUMNS TO
  POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
sql/sql_table.cc:
  Changed mysql_prepare_alter_table() to detect situations in 
  which we some column moved to the first position or some column 
  is dropped and ensure that such ALTER TABLE statements won't
  be carried out using in-place algorithm. The latter could have 
  happened before this patch if new version of table had the same 
  structure as the old one (except the column names).

marko.makela@oracle.com-20110616072721-8bo92ctixq6eqavr

The buf_pool->zip_clean list is only needed for debugging, or for
recomputing buf_pool->page_hash when resizing the buffer pool. Buffer
pool resizing was never fully implemented. Remove the resizing code,
and define buf_pool->zip_clean only in debug builds.

buf_pool->zip_clean, buf_LRU_insert_zip_clean(): Enclose in
#if defined UNIV_DEBUG || UNIV_BUF_DEBUG.

buf_chunk_free(), buf_chunk_all_free(), buf_pool_shrink(),
buf_pool_page_hash_rebuild(), buf_pool_resize(): Remove (unreachable code).

rb:671 approved by Inaam Rana

There is an apparent problem with page_zip_clear_rec().
In btr_cur_optimistic_update() we do this:

	page_cur_delete_rec(page_cursor, index, offsets, mtr);
...
	rec = btr_cur_insert_if_possible(cursor, new_entry, 0/*n_ext*/, mtr);
	ut_a(rec); /* <- We calculated above the insert would fit */

The problem is that page_cur_delete_rec() could fill the modification
log while doing page_zip_clear_rec(), requiring recompression for the
btr_cur_insert_if_possible(). In a pathological case, the data could
fail to recompress.

page_zip_clear_rec(): Leave the page modification log alone. Only
clear the necessary fields.

rb:673 approved by Jimmy Yang