Do this in the common plugin.cmake but only if running in PB2
  (If done in manual builds it would create a bzr diff)

will create multiple running events.

A CREATE IF NOT EXIST on an event that existed and was enabled caused
multiple instances of the event to run. Disabling the event didn't  help.
If the event was  dropped, the event stopped running, but when created
again, multiple instances of the event were still running. The only way
to get out of this situation was  to restart the server.

The problem was that Event_db_repository::create_event() didn't return
enough information to discriminate between situation when event didn't
exist and was created and when event did exist and was not created
(but a warning was emitted). As result in the latter case event
was added to in-memory queue of events second time. And this led to
unwarranted multiple executions of the same event.

The solution is to add out-parameter to Event_db_repository::create_event()
method which will signal that event was not created because it already
exists and so it should not be added to the in-memory queue.


mysql-test/r/events_bugs.result:
  Added results for test for Bug#12546938.
mysql-test/t/events_bugs.test:
  Added test for Bug#12546938.
sql/event_db_repository.cc:
  Event_db_repository::create_event was modified: set newly added out-parameter
  event_already_exists to true value if event wasn't created because event
  already existed and IF NOT EXIST clause was present.
sql/event_db_repository.h:
  Added out-parameter 'event_already_exists' to create_event() method.
sql/events.cc:
  Events::create_event was modified: insert new element into
  event queue only if event was actually created.

HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ...
   READ.

Unfortunately both of these approaches have drawbacks which make
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.5 version of this patch switch from read lock to write
lock is done on SQL-layer.

mysql-test/suite/innodb/r/innodb_mysql.result:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
sql/sql_parse.cc:
  Since a temporary table locked by LOCK TABLES can be updated even
  if it was only locked for read we always request TL_WRITE locks
  for such tables at LOCK TABLES time. This allows to avoid 
  discrepancy between locks acquired at LOCK TABLES time and by
  a statement executed under LOCK TABLES. Such a discrepancy has
  caused problems for InnoDB storage engine.
  
  To support this change a part of code implementing LOCK TABLES 
  has been moved to a helper function.

INNODB ASSERTS IN HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE,
TABLE LOCK" into 5.5 tree. 5.5 version of fix will be
committed and pushed separately.

HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The 
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock 
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a 
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will 
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ... 
   READ.

Unfortunately both of these approaches have drawbacks which make 
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.1 version of this patch switch from read lock to write
lock is done inside of InnoDBs handler methods as doing it on 
SQL-layer causes compatibility troubles with FLUSH TABLES WITH
READ LOCK.

mysql-test/suite/innodb/r/innodb_mysql.result:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
  Added test for bug #11762012 - "54553: INNODB ASSERTS IN 
  HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".
storage/innobase/handler/ha_innodb.cc:
  Assume that a temporary table locked by LOCK TABLES can be updated
  even if it was only locked for read and therefore an X-lock should 
  be always requested for such tables.
storage/innodb_plugin/handler/ha_innodb.cc:
  Assume that a temporary table locked by LOCK TABLES can be updated
  even if it was only locked for read and therefore an X-lock should 
  be always requested for such tables.

Two conflicts resolved manually:
Text conflict in sql/log.cc
Text conflict in sql/mysqld.cc

Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order.
The correct order is first LOCK_thread_count and then LOCK_log. This function
does it the other way around. This leads to deadlock when run in parallel
with a thread that takes the two locks in correct order. For example, a thread
that disconnects will take the locks in the correct order.
Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs:
first LOCK_thread_count and then LOCK_log.


mysql-test/suite/binlog/r/binlog_reset_master.result:
  added result file
mysql-test/suite/binlog/t/binlog_reset_master.test:
  Added test case that demonstrates deadlock because of wrong mutex order.
  The deadlock is between two threads:
   - RESET MASTER acquires mutexes in wrong order.
   - client thread shutdown code acquires mutexes in right order.
  Actually, this test case does not produce deadlock in 5.1, probably
  the client thread shutdown code does not hold both mutexes at the same
  time. However, the bug existed in 5.1 (mutexes are taken in the wrong
  order) so we push the test case to 5.1 too, to prevent future
  regressions.
sql/log.cc:
  Change mutex acquisition to the correct order:
  first LOCK_thread_count, then LOCK_log.
sql/mysqld.cc:
  Add debug code to synchronize test case.

Assertion happens due to missing NULL value check in
Item_func_round::fix_length_and_dec() function.
The fix: added NULL value check for second parameter.


mysql-test/r/func_math.result:
  test case
mysql-test/t/func_math.test:
  test case
sql/item_func.cc:
  added NULL value check for second parameter.

Execution of platforms tests are slow/flaky when building on windows.
in PB:mysql-next-mr-opt-team on 2011-05-18 for win x86 debug_max, i see:
-- Looking for FIONREAD
-- Looking for FIONREAD - found
and the build fails.

sql/sql_show.cc:
  Restored DEBUG_SYNC point missed during merge 5.1->5.5

Not for test itself but because it procuces large number of warnings,
  and this may take >90s to filter on slow boxes

Replace global check_timeout with one that calls testcase_timeout for the test

Added --with-gcov option to configure.pl and use that from SETUP.sh

BUG#12578441, reintroduced thd->cleanup() in unlink_thd, removed by mistake, added private interface to this function

Use [g]zip on core file if available, ignore if not
Skip if running named test, and print a line saying what it compressed.

Fix a deadlock in the initial patch. lock_validate() must not hold the
lock system mutex while s-latching a block, because some functions,
such as lock_rec_convert_impl_to_expl(), may be already holding an x-latch
on the block that lock_validate() is interested in while attempting to
acquire the lock system mutex.

This deadlock was not caught by UNIV_SYNC_DEBUG because of
buf_block_dbg_add_level(block, SYNC_NO_ORDER_CHECK).

lock_clust_rec_some_has_impl(), row_get_rec_trx_id(),
lock_rec_queue_validate(), lock_table_other_has_incompatible(),
lock_table_has_to_wait_in_queue(), lock_table_queue_validate():
Add const qualifiers.

row_get_trx_id_offset(): Add const qualifiers. Keep the parameter rec
only in UNIV_DEBUG builds. Inline the function.

lock_rec_validate_page(): Take the buffer block as a parameter, to
avoid a buf_page_get_gen() call in most cases.

lock_rec_validate_page_low(): A version of lock_rec_validate_page()
that assumes that the lock system mutexes are already being held.

lock_rec_get_next_on_page_const(): A const variant of
lock_rec_get_next_on_page().

lock_validate(): Do not release the lock system mutex while
buffer-fixing the block for the lock_rec_validate_page() call.
Releasing the mutex apparently caused the assertion failure.

rb:665 approved by Sunny Bains

Backported from trunk-mtr

------------------------------------------------------------
revno 2876.244.305
revision id marko.makela@oracle.com-20110413082211-e6ouhjz5rmqxcqap
parent  marko.makela@oracle.com-20110413075948-kvytmc37ye1nt7d9
committer  Marko Mäkelä <marko.makela@oracle.com>
branch nick 5.6-innodb
timestamp Wed 2011-04-13 11:22:11 +0300
message:
  Suppress the Bug #58815 (Bug #11765812) assertion failure.

  buf_page_get_gen(): Introduce BUF_GET_POSSIBLY_FREED for suppressing the
  check that the file page must not have been freed.

  btr_estimate_n_rows_in_range_on_level(): Pass BUF_GET_POSSIBLY_FREED and
  explain in the comments why this is needed and why it should be mostly
  harmless to ignore the problem. If InnoDB had always initialized all
  unused fields in data files, no problem would exist.

  This change does not fix the bug, it just "shoots the messenger".

  rb:647 approved by Jimmy Yang

Automerged bzr bundle from bug report into latest mysql-5.5.