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.

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.

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

( Based on review comments)

           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().

in different default schema.

In strict mode, when data truncation or conversion happens,
THD::killed is set to THD::KILL_BAD_DATA.

This is abuse of KILL mechanism to guarantee that execution
of statement is aborted.

The stored procedures execution, on the other hand,
upon detection that a connection was killed, would
terminate immediately, without trying to restore the caller's
context, in particular, restore the caller's current schema.

The fix is, when terminating a stored procedure execution,
to only bypass cleanup if the entire connection was killed,
not in case of other forms of KILL.


mysql-test/r/sp-bugs.result:
  Added result for a test case for bug#54375.
mysql-test/t/sp-bugs.test:
  Added test case for bug#54375.
sql/sp_head.cc:
  sp_head::execute modified: restore saved current db if
  connection is not killed.

- added missing DBUG_RETURN
- fixed whitespace according to coding style.

This bug was introduced in this revision: 
kostja@sun.com-20100727102553-b4n2ojcyfj79l2x7
("A pre-requisite patch for the fix for Bug#52044.")

It happens because close_thread_tables() is now called in
open_and_lock_tables upon failure.  Hence, table is no longer
open when optimizer tries to do cleanup.

Fix: Make sure to do cleanup in st_select_lex_unit::prepare()
upon failure. This way, cleanup() is called before tables are
released.

mysql-test/r/subselect.result:
  Added test case for Bug#57704.
mysql-test/t/subselect.test:
  Added test case for Bug#57704.
sql/sql_union.cc:
  st_select_lex_unit::prepare():  On failure, make sure cleanup()
  is called.

ALTER TABLE RENAME, DISABLE KEYS.

The code of ALTER TABLE RENAME, DISABLE KEYS could
issue a commit while holding LOCK_open mutex.
This is a regression introduced by the fix for
Bug 54453.
This failed an assert guarding us against a potential
deadlock with connections trying to execute
FLUSH TABLES WITH READ LOCK.

The fix is to move acquisition of LOCK_open outside
the section that issues ha_autocommit_or_rollback().
LOCK_open is taken to protect against concurrent
operations with .frms and the table definition
cache, and doesn't need to cover the call to commit.

A test case added to innodb_mysql.test.

The patch is to be null-merged to 5.5, which
already has 54453 null-merged to it.

mysql-test/suite/innodb/r/innodb_mysql.result:
  Added test results for test for bug#56619.
mysql-test/suite/innodb/t/innodb_mysql.test:
  Added test for bug#56619.
sql/sql_table.cc:
  mysql_alter_table() modified: moved acquisition of LOCK_open
  after call to ha_autocommit_or_rollback.

sql/item_func.cc:
  Item_func::fix_fields modified: increased minimal required stack
  size in call to check_stack_overrun().

The problem was that the scheduler function used to handle a
new user connection could use the ER() macro without having a
THD object bound to the current thread. The crash would happen
whenever the function failed to create a new thread to handle a
user connection. Thread creation can fail due to lack or limit
of available resources.

The solution is to simply use the ER_THD() macro instead and pass
to it the THD object which would be bound to the connection.

Fix was tested manually. In a test case, it is too cumbersome to
inject a error in this context.

sql/mysqld.cc:
  Use ER_THD and pass the object.

Quoting from the bug report:

The pstack library has been included in MySQL since version
4.0.0. It's useless and should be removed.

Details: According to its own documentation, pstack only works
on Linux on x86 in 32 bit mode and requires LinuxThreads and a
statically linked binary. It doesn't really support any Linux
from 2003 or later and doesn't work on any other OS.

The --enable-pstack option is thus deprecated and has no effect.

Bug#58041 : Created separate per push and daily collections for 5.5-bugteam. Moved rpl_binlog_row to daily. Run just main suite for ps_row and
embedded per push. Other suites run daily