make_join_select() in sql_select.cc

Caused by incorrect ASSERT introduced by BUG#58456. Quick selects 
may have index == MAX_KEY if it merges indices.

sql/sql_select.cc:
  Removed ASSERT. Quick selects may have index == MAX_KEY if it merges indices.

Automerge from mysql-5.1-bugteam.

Post-push fixes:

  - fixed platform dependent result files
  - appeasing valgrind warnings:
   
    Fault injection was also uncovering a previously existing 
    potential mem leaks. For BUG#46166 testing purposes, fixed 
    by forcing handling the leak when injecting faults.

Merging to latest mysql-5.5-bugteam.

Merging to latest mysql-5.1-bugteam.

            in opt_range.h

In this bug, there are two alternative access plans: 
 * Index merge range access
 * Const ref access

best_access_path() decided that the ref access was preferrable, 
but make_join_select() still decided to point 
SQL_SELECT::quick to the index merge because the table had 
type==JT_CONST which was not handled. 

At the same time the table's ref.key still referred to the 
index the ref access would use indicating that ref access 
should be used. In this state, different parts of the 
optimizer code have different perceptions of which access path
is in use (ref or range).

test_if_skip_sort_order() was called to check if the ref access
needed ordering, but test_if_skip_sort_order() got confused and
requested the index merge to return records in sorted order. 
Index merge cannot do this, and fired an ASSERT.

The fix is to take join_tab->type==JT_CONST into concideration
when make_join_select() decides whether or not to use the 
range access method.

mysql-test/r/join_outer_innodb.result:
  Add test for BUG#58456
mysql-test/t/join_outer_innodb.test:
  Add test for BUG#58456

"load data infile .."  allowed for access to 
unautohorized tables.
Due to a faulty if-statement it was possible to
circumvent the secure_file_priv restriction.


mysql-test/mysql-test-run.pl:
  * Add SECURE_LOAD_PATH environment variable to mtr test cases.
mysql-test/suite/sys_vars/r/secure_file_priv2.result:
  * add test for bug58747
mysql-test/suite/sys_vars/t/secure_file_priv2-master.opt:
  * add test for bug58747
mysql-test/suite/sys_vars/t/secure_file_priv2.test:
  * add test for bug58747
sql/sql_load.cc:
  * Correct faulty if-statement
  * fix indentation
  * move my_stat() block to after is_secure_file_path() check.

           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.

file .\item_subselect.cc, line 836
     
IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.
      
Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Back-ported to 5.0s

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.

The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.

A similar problem existed for stored programs: the changes between
executions didn't have an effect.

Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.

The fix is to check them there as it happens in find_field_in_table_ref().

automatically to place a dependency on the VERSION file.