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.


mysql-test/r/error_simulation.result:
  test case
mysql-test/t/error_simulation.test:
  test case
sql/item_subselect.cc:
  added new flag subselect_single_select_engine::optimize_error
  which is used for error detection which could happen at optimize
  stage.
sql/item_subselect.h:
  added new flag subselect_single_select_engine::optimize_error
sql/sql_select.cc:
  test case

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".

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

Replace part of the patch that Kevin apparently forgot to push.
Fix the bug also in the built-in InnoDB of MySQL 5.1.

I cannot explain why the test case was not failing without the
full patch.

This was rb:762, approved by me.

The problem occurred when indexes are added between the time that an
UNDO record is created and the time that the purge thread comes around
and deletes the old secondary index entries.  The purge thread would
hit an assert when trying to build a secondary index entry for
searching.  The problem was that the old value of those fields were not
in the UNDO record since they were not part of an index when the UPDATE
occured. 
A test case was added to innodb-index.test.

  Added simple cut-off w/warning if > one million lines

               FULLTEXT INDEXES

myisamchk may create incorrect fulltext index for compressed
tables. Incorrect data pointer size was used while creating
fulltext index.

mysql-test/r/myisampack.result:
  A test case for BUG#11761180.
mysql-test/t/myisampack.test:
  A test case for BUG#11761180.
storage/myisam/ft_boolean_search.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
storage/myisam/ft_nlq_search.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
storage/myisam/mi_check.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.
storage/myisam/mi_write.c:
  rec_reflength on share may have adjustments required for
  compressed tables and must be used instead of rec_reflength
  on base info.

  Export $MYSQLD as full path to executable
  $MYSQLD_CMD is executable with minimum required args

  Call handle_error() instead of die() when evaluating these
  Must remember "current command" with link to errors to ignore
  Added test cases to mysqltest.test 

when buffered changes are to be discarded

sync_thread_add_level(level = SYNC_IBUF_INDEX_TREE): Relax a too strict
condition that the thread must not be holding locks below SYNC_FSP_PAGE.
It is perfectly valid to hold any latch above SYNC_IBUF_INDEX_TREE when
acquiring the insert buffer tree latch.

bugs in it - accessing uninitialized ::len member (thanks, Jimmy!)
and a memory leak.

This is a followup to vasil.dimov@oracle.com-20110909070724-jvirxnpkbxieauz5
which disabled the prefetch code.

when buffered changes are to be discarded

ibuf_add_free_page(): Lower the latching order of the newly allocated page
to SYNC_IBUF_TREE_NODE_NEW after latching the insert buffer tree root.

This bug always was bogus UNIV_SYNC_DEBUG alarm. The function
buf_block_dbg_add_level() is a no-op unless UNIV_SYNC_DEBUG is defined.

When there is a secondary index on a column prefix of an externally
stored column and an entry in the secondary index is shorter than the
reserved prefix length, it should mean that the secondary index entry
is holding the complete column value. When comparing this secondary
index column value to the column in the clustered index row, we must
compare the entire prefix that was fetched from the clustered
index. The bug was that we would just compare that the column in the
clustered index starts with the value found in the secondary index
column.

This bug affects only the InnoDB Barracuda formats (ROW_FORMAT=DYNAMIC
and ROW_FORMAT=COMPRESSED), in which columns that are stored off-page
in the clustered index do not contain any prefix in the clustered
index record.

row_sel_sec_rec_is_for_blob(): Add the parameter prefix_len, for
ifield->prefix_len. Add some assertions.

Sorry, I did not manage to produce a test case. This patch does
produce correct results on the data set that Michael isolated on our
test machine. That was with the purge and background rollback
suspended, because they would make the bug go away.

rb:760 approved by Sunny Bains

This change is a followup to
vasil.dimov@oracle.com-20110907145810-v98kldmho23vhhic
which triggered the usage of the prefetch and valgrind tests spat lots of
warnings.

The prefetch code will be removed.

Discussed with:	Marko (over IM)

InnoDB acquires an x-latch on btr_search_latch for certain in-place updates
that do affect the adaptive hash index. These operations do not really need
to be protected by the btr_search_latch:

* updating DB_TRX_ID
* updating DB_ROLL_PTR
* updating PAGE_MAX_TRX_ID
* updating the delete-mark flag

rb:750 approved by Sunny Bains

Tweak the faulty UNIV_SYNC_DEBUG diagnostics a little bit more.

ibuf_add_free_page(): Lower the latching order of the newly allocated page
only after acquiring the ibuf_mutex.

DROP_TABLE_PROC().

With this change I observe a speedup from 6.2s to 0.1s when executing
DROP_TABLE_PROC() during DROP TABLE with 512 foreign keys, like what
is being done in innodb_bug56143.test

This fixes "Bug#11765460 DROP TABLE USES INEFFICIENT METHODS TO REMOVE
FKS/INDEXES FROM INNODB SYS TABLES"

Reviewed by:	Marko

                            (EG: --DEFAULTS-FILE )
  
Updating help message in scripts/mysql_install_db.pl.in file.


scripts/mysql_install_db.pl.in:
  Bug#11765888 58898: MYSQL_INSTALL_DB: NOT ALL OPTIONS DOCUMENTED
                              (EG: --DEFAULTS-FILE )
    
  Updating help message.

                    (EG: --DEFAULTS-FILE )

Added help message for the missing options (--no-defaults,
--defaults-file and --defaults-extra-file).

buf_buddy_relocate(): The ut_time_us() function is needed for
statistics, calculating the total time spent on relocating blocks.
Until now, we invoked ut_time_us() every time buf_buddy_relocate() was
called. Fix: Only call ut_time_us() when the block can be relocated.
After this fix, the reported relocated_usec will no longer include the
time for the page_hash lookup and for acquiring the block mutex.

Approved by Sunny Bains on IM

The original fix was accidentally pushed to mysql-5.1 after the 5.1.59
clone-off in bzr revision id
marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w with thne fix
of Bug#12704861 Corruption after a crash during BLOB update.
It was pushed separately to mysql-5.5 in bzr revision id
marko.makela@oracle.com-20110901184804-2901f6qmuro3jas8.

trx_undo_report_row_operation(): If the page for which the undo log
was too big was empty, commit and start the mini-transaction before
acquiring the rollback segment mutex and freeing the undo page. This
is necessary, because the mini-transaction may be holding lower-order
latches in the levels SYNC_FSP and SYNC_FSP_PAGE.

trx_undo_erase_page_end(): Erase also empty pages, because
trx_undo_report_row_operation() needs to commit the mini-transaction
before freeing the empty page.

rb:756 approved by Sunny Bains

  Link plugin with a copy of string.o
  Copied test from 5.5 but this was dysfunctional, made it work
  Also tested on Windows