was caused by change of thread state name from "Waiting for
table" to "Waiting for table metadata lock" (which has 
happened as part of fix for bug 52044 "FLUSH TABLES WITH READ
LOCK and FLUSH TABLES <list> WITH READ LOCK are incompati").

           on CREATE TABLE .. SELECT I_S.PART

This assert was triggered if an InnoDB table was created using
CREATE TABLE ... AS SELECT where the query used an I_S table, and
a view existed in the database. It would also be triggered for
any statement changing an InnoDB table (e.g. INSERT, UPDATE, DELETE)
which had a subquery referencing an I_S table.

The assert was triggered if open_normal_and_derived_tables() failed
and a statement transaction had been started. This will usually not
happen as tables are opened before a statement transaction is started.
However, e.g. CREATE TABLE ... AS SELECT starts a transaction in order
to insert tuples into the new table. And if the subquery references
an I_S table, all current tables and views can be opened in order to
fill the I_S table on the fly. If a view is discovered, open will fail
as it is instructed to open tables only (OPEN_TABLE_ONLY). This would
cause the assert to be triggered.

The assert was added in the patch for Bug#52044 and was therefore
not in any released versions of the server.

This patch fixes the problem by adjusting the assert to take into
consideration the possibility of tables being opened as part of
an I_S query. This is similar to what is already done for 
close_tables_for_reopen().

Test case added to information_schema_inno.test.

           check_if_table_exists()

This assert was triggered when the server tried to load plugins
while running in embedded server mode. In embedded server mode,
check_if_table_exists() was used to check if mysql.plugin existed
so that ER_NO_SUCH_TABLE could be silently ignored.
The problem was that this check was done without acquiring a metadata
lock on mysql.plugin first. This triggered the assert.

This patch fixes the problem by removing the call to
check_if_table_exists() from plugin_load(). Instead an error handler
which traps ER_NO_SUCH_TABLE is installed before trying to open
mysql.plugin when running in embedded server mode.

No test coverage added since this assert was triggered by 
existing tests running in embedded server mode.

        'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
automatically after the this patch.
BUG#55617 is fixed by this patch too.
            
This is the 5.5 part.
It implements:
- 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
  anything and binlog anything if the table already exists.
  It only generate a warning that table already exists.
- A couple of test cases for the behavior changing.

      
Added InnoDB to the 'default' plugin group, and modified 
the autoconf script so the 'default' group is actually 
built by default.
      
(i.e  ./configure.am == ./configure.am --with-plugins=default ,
instead of being ./configure.am --with-plugins=none )

dict_load_index_low(): Rename the parameter "cached" to "allocated"
and clarify the comments.

Followup to vasil.dimov@oracle.com-20100817063430-inglmzgdtj95t29d
which didn't fully fix the test because the order of the returned
rows was different in embedded and non-embedded version. So the only
way to fix this is to add an ORDER BY clause.

           rpl_ndb.rpl_ndb_2other fails

The two regressions tests failed after WL#5349 was
pushed, since they were writted with the implicit
requirement that MyISAM is the default storage engine.

Adding --default-storage-engine=MyISAM as startup
parameter, to mimic the pre-wl#5349 situation.

lock wait time. Including the InnoDB lock time in the exiting "Lock_time"
output.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm. The endspace test is non-deterministic
because it does not include ORDER BY clause in its queries.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm.

  
This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm. I have manually checked that the new
values are actually the correct ones, for example:
-rows	16
+rows	32
the number of rows returned by the query is 32.

Improve the range estimation algorithm.

Previously:
For a given level the algo knows the number of pages in the requested range and the n

With this change:
Same idea, but peek a few (10) of the intermediate pages to get a better estimate of 

In the bug report one of the examples has a btree with a snippet of the leaf level li
page1(899 records), page2(1 record), page3(1 record), page4(1 record)
so when trying to estimate, the previous algo, assumed there are average (899+1)/2=45
Fix Bug#53761 RANGE estimation for matched rows may be 200 times different

Improve the range estimation algorithm.

Previously:
For a given level the algo knows the number of pages in the requested range
and the number of records on the leftmost and the rightmost page. Then it
assumes all pages in between contain the average between the two border pages
and multiplies this average number by the number of intermediate pages.

With this change:
Same idea, but peek a few (10) of the intermediate pages to get a better
estimate of the average number of records per page. If there are less than 10
intermediate pages then all of them will be scanned and the result will be
precise, not an estimation.

In the bug report one of the examples has a btree with a snippet of the leaf
level like this:
page1(899 records), page2(1 record), page3(1 record), page4(1 record)
so when trying to estimate, the previous algo, assumed there are average
(899+1)/2=450 records per page which went terribly wrong. With this change
page2 and page3 will be read and the exact number of records will be returned.

Approved by:	Sunny (rb://401)

          example files)

The system variable 'thread_concurrency' has been
(re-)enabled on all platforms, to prevent startup
errors.

'thread_concurrency' is unused and has no effect,
on any platform, in MySQL 5.1 and later versions.  It 
will be deprecated, and removed, in context of 
worklog WL#5265

           locks on the table

Fixing the partitioning specifics after TRUNCATE TABLE in
bug-42643 was fixed.

Reorganize of code to decrease the size of the giant switch
in mysql_execute_command, and to prepare for future parser
reengineering. Moved code into Sql_statement objects.

Updated patch according to davi's review comments.

pushdown.
      
NDB supports only a limited set of item nodes for use in engine condition
pushdown. Because of this adding cache for const expression effectively
disabled this optimization.
      
The ndb_serialize_cond function is extended to support Item_cache and treat
it as a constant values.
A helper function called ndb_serialize_const is added. It is used to create
Ndb_cond value node from given const item.

Note that this was originally pushed by Calvin but the was later
reverted by mistake.

bug#54702

The bug was fixed by the patch for Bug 52044.
Add a test case.

into an own implementation file.

The problem was that SHOW CREATE EVENT released all metadata locks
held by the current transaction. This made any exisiting savepoints
invalid, triggering the assert when ROLLBACK TO SAVEPOINT later
was executed.

This patch fixes the problem by making sure SHOW CREATE EVENT only
releases metadata locks acquired by the statement itself.

Test case added to event_trans.test.

           corruption on ADD PARTITION and LOCK TABLE
Bug#53770: Server crash at handler.cc:2076 on
           LOAD DATA after timed out COALESCE PARTITION

5.5 fix for:
Bug#51042: REORGANIZE PARTITION can leave table in an
           inconsistent state in case of crash
Needs to be back-ported to 5.1

5.5 fix for:
Bug#50418: DROP PARTITION does not interact with
           transactions

Main problem was non-persistent operations done
before meta-data lock was taken (53770+53676).
And 53676 needed to keep the table/partitions opened and locked
while copying the data to the new partitions.

Also added thorough tests to spot some additional bugs
in the ddl_log code, which could result in bad state
between the .frm and partitions.

Collapsed patch, includes all fixes required from the reviewers.