NAME_CONST(..) was used wrongly in a HAVING clause, and
should have caused a user error.  Instead, it caused a
segmentation fault.
      
During parsing, the value parameter to NAME_CONST was
specified to be an uninitialized Item_ref object (it
would be resolved later).   During the semantic analysis,
the object is tested, and since it was not initialied,
the server seg.faulted.
      
The fix is to check if the object is initialized
before testing it.  The same pattern has already been
applied to most other methods in the Item_ref class.
      
Bug was introduced by the optimization done as part of
Bug#33546.

Finalize the server flags after any kind of command is executed.
To avoid updating the flag multiple times, reorganize code so that
its invoked only once for each command.

No conflicts

           breaks SBR

The problem was that DROP DATABASE ignored any metadata locks on stored
functions and procedures held by other connections. This made it
possible for DROP DATABASE to drop functions/procedures that were in use
by other connections and therefore break statement based replication.
(DROP DATABASE could appear in the binlog before a statement using a
dropped function/procedure.)

This problem was an issue left unresolved by the patch for Bug#30977
where metadata locks for stored functions/procedures were introduced.

This patch fixes the problem by making sure DROP DATABASE takes
exclusive metadata locks on all stored functions/procedures to be
dropped.

Test case added to sp-lock.test.

Use __builtin_stpcpy only if the system supports stpcpy.
This is necessary as in some cases a call to stpcpy will
be emitted if the built-in can not optimized.

Memory was allocated for storing path names inside
fn_expand(), which were not free:ed anywhere.

This patch fixes the problem by storing the path
names in statically allocated buffers instead,
which is automatically free:ed when the server
exits.

           breaks SBR

This pre-requisite patch refactors the code for dropping tables, used
by DROP TABLE and DROP DATABASE. The patch moves the code for acquiring
metadata locks out of mysql_rm_table_part2() and makes it the
responsibility of the caller. This in preparation of changing the
DROP DATABASE implementation to acquire all metadata locks before any
changes are made. mysql_rm_table_part2() is renamed
mysql_rm_table_no_locks() to reflect the change.

No conflicts

Including adding test in 5.5 requiring --big-test
flag from mysql-test-run.pl and also disabled
tests that fails.

           during EXPLAIN

Before the patch, send_eof() of some subclasses of 
select_result (e.g., select_send::send_eof()) could 
handle being called after an error had occured while others 
could not. The methods that were not well-behaved would trigger
an ASSERT on debug builds. Release builds were not affected.

Consider the following query as an example for how the ASSERT
could be triggered:

A user without execute privilege on f() does
   SELECT MAX(key1) INTO @dummy FROM t1 WHERE f() < 1;
resulting in "ERROR 42000: execute command denied to user..." 

The server would end the query by calling send_eof(). The 
fact that the error had occured would make the ASSERT trigger. 

select_dumpvar::send_eof() was the offending method in the
bug report, but the problem also applied to other 
subclasses of select_result. This patch uniforms send_eof() 
of all subclasses of select_result to handle being called 
after an error has occured. 

The test result differs on windows, since
it writes out 'localhost:<port>' instead of
only 'localhost', since it uses tcp/ip instead
of unix sockets on windows.

Fixed by replacing that column.

Also requires --big-test from some long running tests
and added a weekly run of all test requiring --big-test.

           breaks SBR

This pre-requisite patch removes obsolete and dead code used to remove
raid subdirectories and files during DROP DATABASE.

Other parts of the raid code have already been removed in WL#5498
and the support for MyISAM raid tables was removed in 5.0.

Problem:  with "make package" , many small packages are 
generated, one per CMake COMPONENT, instead of expected single
package. This is due to the new (in cmake 2.8.3) component-based 
install for archive( e.g ZIP,TGZ ) CPack generators.

See http://public.kitware.com/Bug/view.php?id=11452 for discussion.

Fix: use CPACK_MONOLITHIC_INSTALL=1 to enforce single package.
Reset this variable temporarily to 0 for  MSI creation  (MSI needs 
COMPONENTs)

structure buffer).

This is a follow-up for WL#4435. The bug actually existed not only
MYSQL_TYPE_DATETIME type. The problem was that Item_param::set_value()
was written in an assumption that it's working with expressions, i.e.
with basic data types.

There are two different quick fixes here:
  a) Change Item_param::make_field() -- remove setting of
     Send_field::length, Send_field::charsetnr, Send_field::flags and
     Send_field::type.

     That would lead to marshalling all data using basic types to the client
     (MYSQL_TYPE_LONGLONG, MYSQL_TYPE_DOUBLE, MYSQL_TYPE_STRING and
     MYSQL_TYPE_NEWDECIMAL). In particular, that means, DATETIME would be
     sent as MYSQL_TYPE_STRING, TINYINT -- as MYSQL_TYPE_LONGLONG, etc.

     That could be Ok for the client, because the client library does
     reverse conversion automatically (the client program would see DATETIME
     as MYSQL_TIME object). However, there is a problem with metadata --
     the metadata would be wrong (misleading): it would say that DATETIME is
     marshaled as MYSQL_TYPE_DATETIME, not as MYSQL_TYPE_STRING.

  b) Set Item_param::param_type properly to actual underlying field type.
     That would lead to double conversion inside the server: for example,
     MYSQL_TIME-object would be converted into STRING-object
     (in Item_param::set_value()), and then converted back to MYSQL_TIME-object
     (in Item_param::send()).

     The data however would be marshalled more properly, and also metadata would
     be correct.

This patch implements b).

There is also a possibility to avoid double conversion either by clonning
the data field, or by storing a reference to it and using it on Item::send()
time. That requires more work and might be done later.

      MySQL-shared RPM no longer provides mysql-shared

The spec file is changed to explicitly "provide" "mysql-shared"
by the "shared" sub-RPM.

by the patch for Bug#57058.

HANDLER and FLUSH TABLES WITH READ LOCK" and bug #54673
"It takes too long to get readlock for 'FLUSH TABLES
WITH READ LOCK'".

Disable execution of flush_read_lock.test on embedded
server. This test uses too many statements which are
not supported by embedded server.

network when a query was slow.

When a query is slow, sent a special flag to the client
indicating this fact.

Add a test case.
Implement review comments.

Backport version info handling  (Windows-specific) from next-mr. 
Instead of adding ".res" object as linker flag, add  resource file (.rc) file to the source list.
This is more obvious and less error prone method.

Text conflict in mysql-test/suite/perfschema/r/dml_setup_instruments.result
Text conflict in mysql-test/suite/perfschema/r/global_read_lock.result
Text conflict in mysql-test/suite/perfschema/r/server_init.result
Text conflict in mysql-test/suite/perfschema/t/global_read_lock.test
Text conflict in mysql-test/suite/perfschema/t/server_init.test

Before this fix, file io for the binary log file was not accounted properly,
and showed no io at all.

This bug was due to the following issues:

1) file io for the binlog was instrumented:
- sometime as "wait/io/file/sql/binlog"
- sometime as "wait/io/file/sql/MYSQL_LOG"
leading to inconsistent event_names.

2) the binlog file itself was using an IO_CACHE,
but the IO_CACHE implementation in mysys/mf_iocache.c was
not instrumented to make performance schema calls to record file io.

3) The "wait/io/file/sql/MYSQL_LOG" instrumentation was used
for several log files, such as:
- the binary log
- the slow log
- the query log
which caused file io in these different log files to be accounted
against the same instrument.
The instrumentation needs to have a finer grain and report io
in different event_names, because each file really serves a different purpose.

With this fix:
- the IO_CACHE implementation is now instrumented
- the "wait/io/file/sql/MYSQL_LOG" instrument has been removed
- binlog io is now always instrumented with "wait/io/file/sql/binlog"
- the slow log is instrumented with a new name, "wait/io/file/sql/slow_log"
- the query log is instrumented with a new name, "wait/io/file/sql/query_log"

--with-comment correctly
      
Properly convert --with-comment
do not uppercase it, quote as it might contain spaces.

bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ
LOCK" and bug #54673 "It takes too long to get readlock for
'FLUSH TABLES WITH READ LOCK'".

The first bug manifested itself as a deadlock which occurred
when a connection, which had some table open through HANDLER
statement, tried to update some data through DML statement
while another connection tried to execute FLUSH TABLES WITH
READ LOCK concurrently.

What happened was that FTWRL in the second connection managed
to perform first step of GRL acquisition and thus blocked all
upcoming DML. After that it started to wait for table open
through HANDLER statement to be flushed. When the first connection
tried to execute DML it has started to wait for GRL/the second
connection creating deadlock.

The second bug manifested itself as starvation of FLUSH TABLES
WITH READ LOCK statements in cases when there was a constant
stream of concurrent DML statements (in two or more
connections).

This has happened because requests for protection against GRL
which were acquired by DML statements were ignoring presence of
pending GRL and thus the latter was starved.

This patch solves both these problems by re-implementing GRL
using metadata locks.

Similar to the old implementation acquisition of GRL in new
implementation is two-step. During the first step we block
all concurrent DML and DDL statements by acquiring global S
metadata lock (each DML and DDL statement acquires global IX
lock for its duration). During the second step we block commits
by acquiring global S lock in COMMIT namespace (commit code
acquires global IX lock in this namespace).

Note that unlike in old implementation acquisition of
protection against GRL in DML and DDL is semi-automatic.
We assume that any statement which should be blocked by GRL
will either open and acquires write-lock on tables or acquires
metadata locks on objects it is going to modify. For any such
statement global IX metadata lock is automatically acquired
for its duration.

The first problem is solved because waits for GRL become
visible to deadlock detector in metadata locking subsystem
and thus deadlocks like one in the first bug become impossible.

The second problem is solved because global S locks which
are used for GRL implementation are given preference over
IX locks which are acquired by concurrent DML (and we can
switch to fair scheduling in future if needed).

Important change:
FTWRL/GRL no longer blocks DML and DDL on temporary tables.
Before this patch behavior was not consistent in this respect:
in some cases DML/DDL statements on temporary tables were
blocked while in others they were not. Since the main use cases
for FTWRL are various forms of backups and temporary tables are
not preserved during backups we have opted for consistently
allowing DML/DDL on temporary tables during FTWRL/GRL.

Important change:
This patch changes thread state names which are used when
DML/DDL of FTWRL is waiting for global read lock. It is now
either "Waiting for global read lock" or "Waiting for commit
lock" depending on the stage on which FTWRL is.

Incompatible change:
To solve deadlock in events code which was exposed by this
patch we have to replace LOCK_event_metadata mutex with
metadata locks on events. As result we have to prohibit
DDL on events under LOCK TABLES.

This patch also adds extensive test coverage for interaction
of DML/DDL and FTWRL.

Performance of new and old global read lock implementations
in sysbench tests were compared. There were no significant
difference between new and old implementations.

( Based on review comments)