temptable views

The TABLE::key_read field indicates if the optimizer has found that row
retrieval only should access the index tree. The triggered assert
inside close_thread_table() checks that this field has been reset when
the table is about to be closed.

During normal execution, these fields are reset right before tables are
closed at the end of mysql_execute_command(). But in the case of errors,
tables are closed earlier. The patch for Bug#52044 refactored the open
tables code so that close_thread_tables() is called immediately if
opening of tables fails. At this point in the execution, it could
happend that all TABLE::key_read fields had not been properly reset,
therefore triggering the assert.

The problematic statement in this case was EXPLAIN where the query
accessed two derived tables and where the first derived table was
processed successfully while the second derived table was not.
Since it was an EXPLAIN, TABLE::key_read fields were not reset after
successful derived table processing since the state needs to be 
accessible afterwards. When processing of the second derived table
failed, it's corresponding SELECT_LEX_UNIT was cleaned, which caused
it's TABLE::key_read fields to be reset. Since processing failed,
the error path of open_and_lock_tables() was entered and
close_thread_tables() was called. The assert was then triggered due
to the TABLE::key_read fields set during processing of the first
derived table.

This patch fixes the problem by adding a new derived table processor,
mysql_derived_cleanup() that is called after mysql_derived_filling().
It causes cleanup of all SELECT_LEX_UNITs to be called, resetting
all relevant TABLE::key_read fields.

Test case added to derived.test.

Allow users to build without aio if they really want to, by passing
-DIGNORE_AIO_CHECK to cmake.

The problem is a race between a session closing its vio
(i.e. after a COM_QUIT) at the same time it is being killed by
another thread. This could trigger a assertion in vio_close()
as the two threads could end up closing the same vio, at the
same time. This could happen due to the implementation of
SIGNAL_WITH_VIO_CLOSE, which closes the vio of the thread
being killed.

The solution is to serialize the close of the Vio under
LOCK_thd_data, which protects THD data.

No regression test is added as this is essentially a debug
issue and the test case would be quite convoluted as we would
need to synchronize a session that is being killed -- which
is a bit difficult since debug sync points code does not
synchronize killed sessions.

sql/mysqld.cc:
  Drop lock parameter from close_connection, its not necessary
  any more. The newly introduced THD::disconnect method will take
  care of locking.
sql/mysqld.h:
  Change prototype, add a default parameter for the error code.
sql/sql_class.cc:
  In case SIGNAL_WITH_VIO_CLOSE is defined, the active vio is
  closed and cleared. Subsequent calls will only close the vio
  owned by the session.

The MYSQL_LOG::open member function does not take a PSI
key file argument when the PSI interface is not present.

automatically to place a dependency on the VERSION file.

           option for specific compilers

Reorganize the maintainer mode cmake code to allow options
for specific compilers. For now, enable -Wcheck for ICC,
but do not turn warnings into errors.

CMakeLists.txt:
  Move the code that sets options to cmake/maintainer.cmake
cmake/maintainer.cmake:
  Add macros for each specific compiler.

initialization to specific functions. Also, remove a large
block of white space. There shouldn't be any functional
change.

Problem: when inserting supplementary characters to an UCS2 column,
character was silently shrinked to 16-bit value.

Fix: produce a warning on attempt to insert a supplementary character,
and convert to question mark.

  @ mysql-test/r/ctype_many.result
  @ mysql-test/t/ctype_many.test
  Adding tests

  @ strings/ctype-ucs2.c
  Check if wc is greater than the highest value supported (0xFFFF),
  return MY_CS_ILUNI if true.

Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l

 > Bug #54476: crash when group_concat and 'with rollup' in
 >                      prepared statements
 >
 > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
 > could crash the server.
 >
 > The reason was a combination of several facts:
 >
 > 1. The Item_func_group_concat class stores pointers to ORDER
 > objects representing the columns in the ORDER BY clause of
 > GROUP_CONCAT().
 >
 > 2. find_order_in_list() called from
 > Item_func_group_concat::setup() modifies the ORDER objects so
 > that their 'item' member points to the arguments list
 > allocated in the Item_func_group_concat constructor.
 >
 > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
 > the original Item_func_group_concat object could be created by
 > using the Item_func_group_concat::Item_func_group_concat(THD
 > *thd, Item_func_group_concat *item) copy constructor. The
 > latter essentially creates a shallow copy of the source
 > object. Memory for the arguments array is allocated on
 > thd->mem_root, but the pointers for arguments and ORDER are
 > copied verbatim.
 >
 > What happens in the test case is that when executing the query
 > for the first time, after a copy of the original
 > Item_func_group_concat object has been created by
 > JOIN::rollup_make_fields(), find_order_in_list() is called for
 > this new object. It then resolves ORDER BY by modifying the
 > ORDER objects so that they point to elements of the arguments
 > array which is local to the cloned object. When thd->mem_root
 > is freed upon completing the execution, pointers in the ORDER
 > objects become invalid. Those ORDER objects, however, are also
 > shared with the original Item_func_group_concat object which is
 > preserved between executions of a prepared statement. So the
 > first call to find_order_in_list() for the original object on
 > the second execution tries to dereference an invalid pointer.
 >
 > The solution is to create copies of the ORDER objects when
 > copying Item_func_group_concat to not leave any stale pointers
 > in other instances with different lifecycles.


mysql-test/r/func_gconcat.result:
  Test case for bug #54476.
mysql-test/t/func_gconcat.test:
  Test case for bug #54476.
sql/item_sum.cc:
  Copy the ORDER objects pointed to by the elements of the
  'order' array in the copy constructor of
  Item_func_group_concat.
sql/table.h:
  Removed the unused 'item_copy' member of the ORDER class.

Automerging mysql-5.1-bugteam into mysql-5.5-bugteam.

Autmoerging into latest mysql-5.1-bugteam.

Addressing review comments.

Bug#57913 large negative number to string conversion functions crash
String object which is used as result container of the item
has uninitialized 'str_charset' field. This object
might be used later to preform some internal operations
and str_charset field is involved in these operations.
It leads to crash.
The fix is to intialize str_charset in my_decimal2string() func.


mysql-test/r/func_str.result:
  test case
mysql-test/t/func_str.test:
  test case
sql/my_decimal.cc:
  intialize str_charset field for result string
  in my_decimal2string() func.

Backport from 5.5. OK from Anitha G. to push to 5.1.

Removed floor(float_col) tests, enabled floor(decimal_col) tests

--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
  before being populated and it leads to incorrect result

We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:

1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.

2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
   process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.

3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.

Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;

4. Derived tables with subquery where subquery
   is evaluated before table locking(Bug#54475, Bug#52157)

Suggested solution is following:

-Introduce new field LEX::context_analysis_only with the following
 possible flags:
 #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
 #define CONTEXT_ANALYSIS_ONLY_VIEW    2
 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
 context analysis operation
-Item_subselect::const_item() returns
 result depending on LEX::context_analysis_only.
 If context_analysis_only is set then we return
 FALSE that means that subquery is non-const.
 As all subquery types are wrapped by Item_subselect
 it allow as to make subquery non-const when
 it's necessary.


mysql-test/r/derived.result:
  test case
mysql-test/r/multi_update.result:
  test case
mysql-test/r/view.result:
  test case
mysql-test/suite/innodb/r/innodb_multi_update.result:
  test case
mysql-test/suite/innodb/t/innodb_multi_update.test:
  test case
mysql-test/suite/innodb_plugin/r/innodb_multi_update.result:
  test case
mysql-test/suite/innodb_plugin/t/innodb_multi_update.test:
  test case
mysql-test/t/derived.test:
  test case
mysql-test/t/multi_update.test:
  test case
mysql-test/t/view.test:
  test case
sql/item.cc:
  --removed unnecessary code
sql/item_cmpfunc.cc:
  --removed unnecessary checks
  --THD::is_context_analysis_only() is replaced with LEX::is_ps_or_view_context_analysis()
sql/item_func.cc:
  --refactored context analysis checks
sql/item_row.cc:
  --removed unnecessary checks
sql/item_subselect.cc:
  --removed unnecessary code
  --added DBUG_ASSERT into Item_subselect::exec()
    which asserts that subquery execution can not happen
    if LEX::context_analysis_only is set, i.e. at context
    analysis stage.
  --Item_subselect::const_item()
    Return FALSE if LEX::context_analysis_only is set.
    It prevents subquery evaluation in ::fix_fields &
    ::fix_length_and_dec at context analysis stage.
sql/item_subselect.h:
  --removed unnecessary code
sql/mysql_priv.h:
  --Added new set of flags.
sql/sql_class.h:
  --removed unnecessary code
sql/sql_derived.cc:
  --added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_lex.cc:
  --init LEX::context_analysis_only field
sql/sql_lex.h:
  --New LEX::context_analysis_only field
sql/sql_parse.cc:
  --removed unnecessary code
sql/sql_prepare.cc:
  --removed unnecessary code
  --added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_select.cc:
  --refactored context analysis checks
sql/sql_show.cc:
  --added LEX::context_analysis_only analysis intialization/cleanup
sql/sql_view.cc:
  --added LEX::context_analysis_only analysis intialization/cleanup

  
On this platform we seem to get lots of other signals
while waiting for SIGKILL to be delivered.

Solution: use sigsuspend(<all signals blocked>)



dbug/dbug.c:
  New function _db_suicide_() which does kill(myself, -9) and then waits forever.
include/my_dbug.h:
  Let DBUG_SUICE wait forever until the KILL signal is delivered, and process dies.

Auto increment value wraps when performing a bulk insert with
auto_increment_increment and auto_increment_offset greater than
one.
The fix:
If overflow happened then return MAX_ULONGLONG value as an
indication of overflow and check this before storing the
value into the field in update_auto_increment().



mysql-test/r/auto_increment.result:
  test case
mysql-test/suite/innodb/r/innodb-autoinc.result:
  test case fix
mysql-test/suite/innodb/t/innodb-autoinc.test:
  test case fix
mysql-test/suite/innodb_plugin/r/innodb-autoinc.result:
  test case fix
mysql-test/suite/innodb_plugin/t/innodb-autoinc.test:
  test case fix
mysql-test/t/auto_increment.test:
  test case
sql/handler.cc:
  If overflow happened then return MAX_ULONGLONG value as an
  indication of overflow and check this before storing the
  value into the field in update_auto_increment().

Explain fails at fix_fields stage and some items are left unfixed,
particulary Item_group_concat. Item_group_concat::orig_args field
is uninitialized in this case and Item_group_concat::print call 
leads to crash.
The fix:
move the initialization of Item_group_concat::orig_args
into constructor.


mysql-test/r/func_gconcat.result:
  test case
mysql-test/t/func_gconcat.test:
  test case
sql/item_sum.cc:
  move the initialization of Item_group_concat::orig_args
  into constructor.

The tests generates 4 Billion rows which timeouts.

Removed the test from the default weekly run.

 my_seek() and my_tell() functions now honour MY_WME flag.


include/mysys_err.h:
  Fix for bug#48451: my_seek and my_tell ignore MY_WME flag
    - EE_CANT_SEEK added, used in my_seek() and my_tell() functions.
mysys/errors.c:
  Fix for bug#48451: my_seek and my_tell ignore MY_WME flag
    - EE_CANT_SEEK added, used in my_seek() and my_tell() functions.
mysys/my_seek.c:
  Fix for bug#48451: my_seek and my_tell ignore MY_WME flag
    - my_seek() and my_tell() handle MY_WME flag.
mysys/my_symlink.c:
  Fix for bug#48451: my_seek and my_tell ignore MY_WME flag
    - __attribute__((unused)) removed, as myf MyFlags is
  actually used in the my_realpath() function.
storage/myisam/ha_myisam.cc:
  Fix for bug#48451: my_seek and my_tell ignore MY_WME flag
    - check my_seek() result.

Fixed the references to security_ctx->priv_user
to be real char * pointers instead of a C array name reference.
This is somehow important for some 3d party 
dtrace replacements

include/mysql/plugin_audit.h:
  Connection auditing class.
include/mysql/plugin_audit.h.pp:
  Connection auditing class.
sql/mysqld.cc:
  Notify disconnect to auditing.
sql/sql_audit.cc:
  Connection class event dispatcher.
sql/sql_audit.h:
  mysql_audit_notify() is not available in embedded.
sql/sql_connect.cc:
  Notify connect to auditing.
sql/sql_parse.cc:
  Notify user change to auditing.

  
On this platform we seem to get lots of other signals
while waiting for SIGKILL to be delivered.

Solution: use sigsuspend(<all signals blocked>)



dbug/dbug.c:
  New function _db_suicide_() which does kill(myself, -9) and then waits forever.
include/my_dbug.h:
  Let DBUG_SUICE wait forever until the KILL signal is delivered, and process dies.

DROP/CREATE SCHEMA, CREATE TABLE, REPAIR.

The cause of assert was concurrent execution of
DROP DATABASE and REPAIR TABLE where first statement
deleted table's file .TMD at the same time as
REPAIR TABLE tried to read file details from the old file
that was just removed.

Additionally was fixed trouble when DROP TABLE try delete
all files belong to table being dropped at the same time
when REPAIR TABLE statement has just deleted .TMD file.

No regression test added because this would require adding a
sync point to mysys/my_redel.c. Since this bug is not present in
5.5+, adding test coverage was considered unnecessary.
The patch has been verified using RQG testing.


sql/sql_db.cc:
  mysql_rm_known_files() modified: ignore possible ENOENT error
  when trying delete all table's files. Such aggressive 
  algorithm permits skip already deleted (in another thread)
  files.
  
  Installation of Drop_table_error_handler as internal error handler
  moved from mysql_rm_db() to mysql_rm_knowns_files() near to place
  where source of possible errors (call to mysql_rm_table_part2) located.
storage/myisam/mi_check.c:
  mi_repair() was modified: set param->retry_repair= 0
  in order to don't call following failover procedure
  in ha_myisam::repair().