sql/sql_acl.cc:
  Must use DBUG_RETURN in a function instrumented with DBUG_ENTER.

mysql-test/r/func_math.result:
  Add test for Bug #58137
mysql-test/t/func_math.test:
  Add test for Bug #58137
sql/field.cc:
  Skip calling my_gcvt() if we are trying to insert a double into a char(0) column.

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.

include/m_string.h:
  The expansion of stpcpy (in glibc) causes warnings if the
  return value of strmov is not being used. Since stpcpy is
  a GNU extension and the expansion ends up using a built-in
  provided by GCC, use the compiler provided built-in directly
  when possible. Nonetheless, the C library must have stpcpy
  as a call 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.

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

mysql-test/collections/default.weekly:
  Added all tests requiring --big-test in alphabetical order
mysql-test/r/information_schema-big.result:
  Updated result
mysql-test/r/variables-big.result:
  updated results
mysql-test/t/disabled.def:
  Added tests that fails (has not been run
  regularly since they need --big-test)

           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. 

mysql-test/r/not_embedded_server.result:
  Added test for BUG#54812
mysql-test/t/not_embedded_server.test:
  Added test for BUG#54812
sql/sql_class.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
sql/sql_insert.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
  Also fix call to abort() in select_create::send_eof(), which was supposed to abort the result set, not terminate the server. This call to abort() should have been changed when the function was renamed from abort_result_set() but was forgotten. New test case added by BUG#54812 covered this line and terminated server.
sql/sql_prepare.cc:
  send_eof() of all subclasses of select_result can now handle being
  called after an error has occured.
sql/sql_update.cc:
  send_eof() of all subclasses of select_result can now 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.

mysql-test/collections/default.weekly:
  Added a run of big-test (already exists in 5.5).
mysql-test/r/variables-big.result:
  Updated results
mysql-test/suite/parts/t/part_supported_sql_func_innodb.test:
  requiring --big-test since the test takes long time
mysql-test/suite/parts/t/partition_alter1_1_2_innodb.test:
  requiring --big-test since the test takes long time
mysql-test/suite/parts/t/partition_alter1_2_innodb.test:
  requiring --big-test since the test takes long time
mysql-test/suite/parts/t/partition_alter4_innodb.test:
  requiring --big-test since the test takes long time
mysql-test/t/disabled.def:
  Disabled two tests since they fail and was already
  reported as bugs (but was never run since they requires
  --big-test flag).
mysql-test/t/variables-big.test:
  Replacing column 3 in process list since it
  is not the same on windows as in unix.

rb://502 approved by Sunny Bains

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.

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.

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.

thr_local_create(): Initialize local->slot_no to ULINT_UNDEFINED.
thr_local_validate(): Allow local->slot_no to be ULINT_UNDEFINED.

( Based on review comments)

This fix is a follow up on the fix for similar issue 56761.

When sanitizing data read from the events_waits_history_long table,
the code needs also to sanitize the schema_name / object_name / file_name pointers,
because such pointers could also hold invalid values.
Checking the string length alone was required but not sufficient.

This fix verifies that:
- the table schema and table name used in table io events
- the file name used in file io events
are valid pointers before dereferencing these pointers.

Also delete dict_update_statistics() and rename dict_update_statistics_low()
to dict_update_statistics() because the only thing that distinguished those
two functions was the removed parameter.

           with on duplicate key update

There was a missed corner case in the partitioning
handler, which caused the next_insert_id to be changed
in the second level handlers (i.e the hander of a partition),
which caused this debug assertion.

The solution was to always ensure that only the partitioning
level generates auto_increment values, since if it was done
within a partition, it may fail to match the partition
function.

mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Added tests
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
  updated results
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  updated results
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  updated results
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  updated results
sql/ha_partition.cc:
  In <engine>::write_row the auto_inc value is generated
  through handler::update_auto_increment (which calls <engine>::get_auto_increment() if needed).
  If:
  * INSERT_ID was set to 0
  * it was updated to 0 by 'INSERT ... ON DUPLICATE KEY UPDATE' and changed partitions for the row
  Then it would try to generate a auto_increment value in the
  <engine for a specific partition>::write_row, which will
  trigger the assert.
  
  So the solution is to prevent this by,
  in ha_partition::write_row set auto_inc_field_not_null and
  add MODE_NO_AUTO_VALUE_ON_ZERO
  in ha_partition::update_row (when changing partition) temporary
  set table->next_number_field to NULL which calling the
  partitions ::write_row().