Server crashed during a sort order optimization
of a dependent subquery:

SELECT
    (SELECT t1.a FROM t1, t2
      WHERE t1.a = t2.b AND t2.a = t3.c
      ORDER BY t1.a)
  FROM t3;


Bitmap of tables, that the reference to outer table
column uses, in addition to the regular table bit
has the OUTER_REF_TABLE_BIT bit set.
The only_eq_ref_tables function traverses this map
bit by bit simultaneously with join->map2table list.
Obviously join->map2table never contains an entry
for the OUTER_REF_TABLE_BIT pseudo-table, so the
server crashed there.


The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).


mysql-test/r/order_by.result:
  Added test case for bug #39844.
mysql-test/t/order_by.test:
  Added test case for bug #39844.
sql/sql_select.cc:
  Bug #39844: Query Crash Mysql Server 5.0.67
  
  The only_eq_ref_tables function has been modified
  to traverse regular table bits only like the
  update_depend_map function (resetting of the
  OUTER_REF_TABLE_BIT there is enough, but
  resetting of the whole set of PSEUDO_TABLE_BITS
  is used there for sure).

Added the missing DROP TABLE

mysql-test/r/windows.result:
  Bug #39958: added the missing DROP TABLE
mysql-test/t/windows.test:
  Bug #39958: added the missing DROP TABLE

The problem is that the function used by the server to increase
the thread's priority (pthread_setschedparam) has the unintended
side-effect of changing the calling thread scheduling policy,
possibly overwriting a scheduling policy set by a sysadmin.

The solution is to rely on the pthread_setschedprio function, if
available, as it only changes the scheduling priority and does not
change the scheduling policy. This function is usually available on
Solaris and Linux, but it use won't work by default on Linux as the
the default scheduling policy only accepts a static priority 0 -- this
is acceptable for now as priority changing on Linux is broken anyway.

configure.in:
  Check for the existence of the pthread_setschedprio function.
include/my_pthread.h:
  Use the pthread_setschedprio function to set the thread priority
  if the function is available.

The problem is that MySQL's 'fast' mutex implementation uses the
random() routine to determine the spin delay. Unfortunately, the
routine interface is not thead-safe and some implementations (eg:
glibc) might use a internal lock to protect the RNG state, causing
excessive locking contention if lots of threads are spinning on
a MySQL's 'fast' mutex. The code was also misusing the value
of the RAND_MAX macro, this macro represents the largest value
that can be returned from the rand() function, not random().

The solution is to use the quite simple Park-Miller random number
generator. The initial seed is set to 1 because the previously used
generator wasn't being seeded -- the initial seed is 1 if srandom()
is not called.

Futhermore, the 'fast' mutex implementation has several shortcomings
and provides no measurable performance benefit. Therefore, its use is
not recommended unless it provides directly measurable results.


include/my_pthread.h:
  Add field to keep the RNG state.
mysys/thr_mutex.c:
  Use a palliative per-mutex rng state to determine the spin delay.
  The RNG is not thread-safe but jumping a few sequences in the RNG
  is harmless.

The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.

The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.

mysql-test/r/limit.result:
  Add test case result for Bug#37075
mysql-test/t/limit.test:
  Add test case for Bug#37075
sql/sql_lex.cc:
  Check for truncation of the offset value. If value was
  truncated, set to the maximum possible value.

The problem is that field names constructed due to wild-card
expansion done inside a stored procedure could point to freed
memory if the expansion was performed after the first call to
the stored procedure.

The problem was solved by patch for Bug#38691. The solution
was to allocate the database, table and field names in the
in the statement memory instead of table memory.

mysql-test/r/sp.result:
  Add test case result for Bug#38823
mysql-test/t/sp.test:
  Add test case for Bug#38823
sql/item.cc:
  Remark that this also impacts wildcard expansion inside SPs.

Select with a "NULL NOT IN" condition containing complex
subselect from the same table as in the outer select failed
with an assertion.


The failure was caused by a concatenation of circumstances:
1) an inner select was optimized by make_join_statistics to use
   the QUICK_RANGE_SELECT access method (that implies an index
   scan of the table);
2) a subselect was independent (constant) from the outer select;
3) a condition was pushed down into inner select.

During the evaluation of a constant IN expression an optimizer
temporary changed the access method from index scan to table
scan, but an engine handler was already initialized for index
access by make_join_statistics. That caused an assertion.


Unnecessary index initialization has been removed from
the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
reinvokes this initialization).


mysql-test/r/subselect3.result:
  Added test case for bug #37894.
mysql-test/t/subselect3.test:
  Added test case for bug #37894.
sql/opt_range.cc:
  Bug #37894: Assertion in init_read_record_seq in handler.h line 1444
  
  Unnecessary index initialization has been removed from
  the QUICK_RANGE_SELECT::init method (QUICK_RANGE_SELECT::reset
  reinvokes this initialization).

            with COALESCE and JOIN

The server returned to a client the VARBINARY column type
instead of the DATE type for a result of the COALESCE,
IFNULL, IF, CASE, GREATEST or LEAST functions if that result
was filesorted in an anonymous temporary table during
the query execution.

For example:
  SELECT COALESCE(t1.date1, t2.date2) AS result
    FROM t1 JOIN t2 ON t1.id = t2.id ORDER BY result;


To create a column of various date/time types in a
temporary table the create_tmp_field_from_item() function
uses the Item::tmp_table_field_from_field_type() method
call. However, fields of the MYSQL_TYPE_NEWDATE type were
missed there, and the VARBINARY columns were created
by default.
Necessary condition has been added.


mysql-test/r/metadata.result:
  Added test case for bug #39283.
mysql-test/t/metadata.test:
  Added test case for bug #39283.
sql/sql_select.cc:
  Bug #39283: Date returned as VARBINARY to client for queries
              with COALESCE and JOIN
  
  To create a column of various date/time types in a
  temporary table the create_tmp_field_from_item() function
  uses the Item::tmp_table_field_from_field_type() method
  call. However, fields of the MYSQL_TYPE_NEWDATE type were
  missed there, and the VARBINARY columns were created
  by default.
  Necessary condition has been added.

 - fixed an unitialized memory read
 - fixed a compilation warning
 - added a suppression for FC9 x86_64

mysql-test/valgrind.supp:
  Bug #3214: added a suppression for FC9 x86_64
sql/item_func.cc:
  Bug #32124
   - fixed an unitialized memory read
   - fixed a compilation warning

           derived table cause crash

When a multi-UPDATE command fails to lock some table, and
subsequently succeeds, the tables need to be reopened if
they were altered. But the reopening procedure failed for
derived tables.

Extra cleanup has been added.


mysql-test/r/lock_multi.result:
  Added test case for bug #38499.
mysql-test/t/lock_multi.test:
  Added test case for bug #38499.
sql/sql_union.cc:
  Bug#38499: flush tables and multitable table update with
             derived table cause crash
  
  Obsolete assertion has been removed.
sql/sql_update.cc:
  Bug#38499: flush tables and multitable table update with
             derived table cause crash
  
  Extra cleanup for derived tables has been added:
  1) unit.cleanup(),
  2) unit->reinit_exec_mechanism().

 Fixed the handling of system variable retrieval
in prepared statements : added a cleanup method
that clears up the cache and restores the 
original scope of the variable (which is overwritten
at fix_fields()).

sql/item_func.cc:
  ug #32124: 
   - preserve the requested variable scope
   - clean up the cache and restore the variable
     scope for prepared statements.
sql/item_func.h:
  Bug #32124: preserve the requested variable scope

TRIGGERS.SQL_MODE, EVENTS.SQL_MODE, TRIGGERS.DEFINER:
field type is changed to VARCHAR.


mysql-test/r/information_schema.result:
  result fix
mysql-test/r/show_check.result:
  result fix
mysql-test/suite/funcs_1/r/is_columns_is.result:
  result fix
mysql-test/suite/funcs_1/r/is_events.result:
  result fix
mysql-test/suite/funcs_1/r/is_triggers.result:
  result fix
sql/sql_show.cc:
  TRIGGERS.SQL_MODE, EVENTS.SQL_MODE, TRIGGERS.DEFINER:
  field type is changed to VARCHAR.

The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
table reconstruction.
The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.


mysql-test/r/alter_table.result:
  test result
mysql-test/t/alter_table.test:
  test case
sql/sql_table.cc:
  The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
  table reconstruction.
  The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.

Fixed a compilation warning

Hide "Table doesn't exist" errors if the table belongs to a merge table.


mysql-test/r/merge.result:
  result fix
mysql-test/t/merge.test:
  test case
sql/sql_base.cc:
  Hide "Table doesn't exist" errors if the table belongs to a merge table.

The problem: table_open_method is not calculated properly if '*' is used in 'select'
The fix: added table_open_method calculation for such case


mysql-test/r/information_schema.result:
  test result
mysql-test/t/information_schema.test:
  test case
sql/sql_show.cc:
  The problem: table_open_method is not calculated properly if '*' is used in 'select'
  The fix: added table_open_method calculation for such case

                 
When running Stored Routines the Status Variable "Questions" was wrongly
incremented. According to the manual it should contain the "number of
statements that clients have sent to the server"
              
Introduced a new status variable 'questions' to replace the query_id
variable which currently corresponds badly with the number of statements
sent by the client.
            
The new behavior is ment to be backward compatible with 4.0 and at the
same time work with new features in a similar way.
            
This is a backport from 6.0

mysql-test/r/status2.result:
  Added test case
mysql-test/t/status2.test:
  Added test case
sql/mysqld.cc:
  Introduced a new status variable 'questions' to replace the query_id
  variable which currently corresponds badly with the number of statements
  sent by the client.
sql/sql_class.h:
  Introduced a new status variable 'questions' to replace the query_id
  variable which currently corresponds badly with the number of statements
  sent by the client.
sql/sql_parse.cc:
  To be backward compatible with 4.0 and at the same time extend the 
  interpretation of the Question variable, it should be increased on
  all COM-commands but COM_STATISTICS, COM_PING, COM_STMT_PREPARE,
  COM_STMT_CLOSE and COM_STMT_RESET.
  Since COM_QUERY can process multiple statements, there has to be an
  extra increase there as well.
sql/sql_show.cc:
  Removed deprecated SHOW_QUESTION status code.
sql/structs.h:
  Removed deprecated SHOW_QUESTION status code.