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.

               WITH LIBEDIT

Libedit won't build on platforms that do not provide
"sys/cdefs.h".

Removed the inclusion of cdefs.h from all files
other that sys.h, which includes this file only
when the header is found while configuring.

Buffer over-run on all platforms, crash on windows, wrong result on other platforms,
when rounding numbers which start with 999999999 and have
precision = 9 or 18 or 27 or 36 ...

Updated libedit library.

hash index at shutdown

btr_search_disable(): Just drop the entire adaptive hash index,
without dropping every record separately.

buf_pool_clear_hash_index(): Renamed and simplified from
buf_pool_drop_hash_index(). Set block->index = NULL for every block in
the buffer pool. Do not release the btr_search_latch. The caller will
have to adjust other data structures.

Remove block->is_hashed. It is redundant, should be always equal to
block->index != NULL.

Remove btr_search_fully_disabled, btr_search_enabled_mutex, and
SYNC_SEARCH_SYS_CONF. We drop the AHI in one pass, without releasing
the btr_search_latch in between.

Replace void* with const rec_t* and add assertions on btr_search_latch
and btr_search_enabled to ha0ha.h, ha0ha.ic, ha0ha.c.

page_set_max_trx_id(): Ignore the adaptive hash index. I forgot to
push this in rb:750.

btr0sea.c: Always after acquiring btr_search_latch, check for
block->index==NULL or !btr_search_enabled. We can now set
block->index=NULL while only holding btr_search_latch in exclusive
mode. Always acquire btr_search_latch before reading block->index,
except in shortcuts when testing for block->index == NULL.

ha_clear(), ha_search(): Unused function, remove.

buf_page_peek_if_search_hashed(): Remove. This function may avoid
latching a page at the cost of doing a duplicate buf_pool->page_hash
lookup.

rb:775 approved by Inaam Rana

bug#11766457 - adjusting/modifying the the tests as tests were failing if system time zone is set differently.

 
A buffer large enough to hold the query _plus_ some additional
data is allocated before parsing is started.   The additional data 
is used by the query cache, and consists of the name of the current 
database and a set of flags.
 
When a packet containing multiple SQL statements is sent to the
server and one of the statements changes the current database
(a "USE <db>" statement), and the name of the new current database 
is longer than of the previous,  there is not enough space in the 
buffer for the new name, and we write out over the buffer boundary.

The fix adds an extra field to store the number of bytes
allocated to the database name in the buffer.  If the current
database name changes, and the new name is longer than the
previous one, we refuse to cache the query.

Problematic query:
insert ignore into `t1_federated` (`c1`) select `c1` from  `t1_local` a
where not exists (select 1 from `t1_federated` b where a.c1 = b.c1);
When this query is killed in another connection it could lead to crash.
The problem is follwing:
An attempt to obtain table statistics for subselect table in killed query
fails with an error. So JOIN::optimize() for subquery is failed but
it does not prevent further subquery evaluation.
At the first subquery execution JOIN::optimize() is called
(see subselect_single_select_engine::exec()) and fails with
an error. 'executed' flag is set to TRUE and it prevents
further subquery evaluation. At the second call
JOIN::optimize() does not happen as 'JOIN::optimized' is TRUE
and in case of uncacheable subquery the 'executed' flag is set
to FALSE before subquery evaluation. So we loose 'optimize stage'
error indication (see subselect_single_select_engine::exec()).
In other words 'executed' flag is used for two purposes, for
error indication at JOIN::optimize() stage and for an
indication of subquery execution. And it seems it's wrong
as the flag could be reset.

rw_lock_x_lock_func(): Assert that the thread is not already holding
the lock in a conflicting mode (RW_LOCK_SHARED).

rw_lock_s_lock_func(): Assert that the thread is not already holding
the lock in a conflicting mode (RW_LOCK_EX).

Bug 12980094 - ASSERTION IN INNODB DETECTED IN RQG_PARTITION_DDL
Bug 13034534 - RQG TESTS FAIL ON WINDOWS WITH CRASH NEAR RW_LOCK_DEBUG_PRINT

All access to struct rw_lock_debug_struct must be protected by rw_lock_debug_mutex_enter().

Change the RPM spec file so that each RPM "obsoletes" the corresponding RPMs
of all (other) configurations, so a "server" RPM of any configuration
can replace the "server" RPM of any other configuration on a "rpm -U".

Bug#11765687 (MySQL58677): No privilege on table / view, but can know #rows / underlying table's name

1 - If a user had SHOW VIEW and SELECT privileges on a view and
this view was referencing another view, EXPLAIN SELECT on the outer
view (that the user had privileges on) could reveal the structure
of the underlying "inner" view as well as the number of rows in
the underlying tables, even if the user had privileges on none of
these referenced objects.

This happened because we used DEFINER's UID ("SUID") not just for
the view given in EXPLAIN, but also when checking privileges on
the underlying views (where we should use the UID of the EXPLAIN's
INVOKER instead).

We no longer run the EXPLAIN SUID (with DEFINER's privileges).
This prevents a possible exploit and makes permissions more
orthogonal.

2 - EXPLAIN SELECT would reveal a view's structure even if the user
did not have SHOW VIEW privileges for that view, as long as they
had SELECT privilege on the underlying tables.

Instead of requiring both SHOW VIEW privilege on a view and SELECT
privilege on all underlying tables, we were checking for presence
of either of them.

We now explicitly require SHOW VIEW and SELECT privileges on
the view we run EXPLAIN SELECT on, as well as all its
underlying views. We also require SELECT on all relevant
tables. 

SYSTEM VARIABLE NAME SQL_MAX_JOIN_SI 

BACKGROUND:

ER_TOO_BIG_SELECT refers to SQL_MAX_JOIN_SIZE, which is the
old name for MAX_JOIN_SIZE.

FIX:

Support for old name SQL_MAX_JOIN_SIZE is removed in MySQL 5.6
and is renamed as MAX_JOIN_SIZE.So the errmsg.txt 
and mysql.cc files have been updated and the corresponding result
files have also been updated.

                      CREATE_TIME IN INFORMATION_SC

It was impossible to determine MEMORY table creation time,
since it wasn't stored/exposed.

With this patch creation time is saved and it is available via
I_S.TABLES.CREATE_TIME.

Note: it was decided that additional analysis is required before
implementing UPDATE_TIME. Thus this patch doesn't store UPDATE_TIME.

  Added 'innodb_file_format_check' as variable to ignore change to.
  Tests that had to restore this amended
  Two tests assumed it to be Antelope, make sure these run on a freshly
    started server
  For 5.5, apparently innodb_file_format_max is the one to ignore