The problem from a user point of view was that on Solaris the
time related functions (e.g. NOW(), SYSDATE(), etc) would always
return a fixed time.

This bug was happening due to a logic in the time retrieving
wrapper function which would only call the time() function every
half second. This interval between calls would be calculated
using the gethrtime() and the logic relied on the fact that time
returned by it is monotonic.

Unfortunately, due to bugs in the gethrtime() implementation,
there are some cases where the time returned by it can drift
(See Solaris bug id 6600939), potentially causing the interval
calculation logic to fail.

Since newer versions of Solaris (10+) have alleviated the
performance degradation associated with time(2), the solution is
to simply directly rely on time() at each invocation.

This simplification has an upside that it allows us to eliminate
a lock which was used to control access to the variables used
to track the half second interval, thus improving the overall
scalability of timekeeping related functions (e.g. NOW()).

Benchmarks runs have shown no significant degradation associated
with this change. With this, there are actually improvements in
performance for cases involving many connections.

In summary, the changes introduced by this patch are:

a) my_time() and my_micro_time_and_time() no longer use gethrtime().
   Instead, time() and gettimeofdate() are used correspondingly.

b) my_micro_time() is changed to not use gethrtime() so as to
   have the same time source as my_micro_time_and_time().
   There shouldn't be any performance impact from this change
   since this function is used only a few times during statement
   execution and, on Solaris, gettimeofday() shows acceptable
   performance.

mysys/my_getsystime.c:
  Use time() even if gethrtime() is available. Remove logic which
  relied on gethrtime() to only call time() every half second.
  Since gethrtime() is not used anymore, also remove it from
  my_micro_time() to keep a common time source.
  
  Also, function comments are cleaned up (fixed typos and wrong
  information) and converted to doxygen.
mysys/my_thr_init.c:
  Remove mutex which is no longer used.
mysys/mysys_priv.h:
  Remove mutex which is no longer used.

Fixed incorrect checks in join_read_const_table() for when to 
accept a non-existing, or empty const-row as a part of the const'ified 
set of tables.
      
Intention of this test is to only accept NULL-rows if this table is outer joined
into the resultset. (In case of an inner-join we can conclude at this point that 
resultset will be empty, end we want to return 'error' to signal this.)
      
Initially 'maybe_null' is set to the same value as 'outer_join' in 
setup_table_map(), mysql_priv.h ~line 2424. Later simplify_joins() will
attemp to replace outer joins by inner join whenever possible. This
will cause 'outer_join' to be updated. However, 'maybe_null' is *not* updated
to reflect this rewrite as this field is used to currectly set the 'nullability'
property for the columns in the resultset.
      
We should therefore change join_read_const_table() to check the 'outer_join'
property instead of 'maybe_null', as this correctly reflect the nullability of
the *execution plan* (not *resultset*).

            null from mysql_store_result.

mysqlslap segfaults at a point when it tries to fetch rows from
the result set.

Under some circumstances, mysql_store_result can return 'NULL',
even after query execution (mysql_query) succeeds, and eventually
a segfault might occur if same unchecked return value is passed
to mysql_fetch_row.

Fixed by adding a check on mysql_store_result's return value.


client/mysqlslap.c:
  Bug#59109 : mysqlslap crashes on mysql_fetch_row after ignoring
              null from mysql_store_result.
  
  Added a check on mysql_store_result's return value. A 'NULL' return
  value here shows an erroneous situation as mysql_field_count has already
  reported a non-zero value.

An incorrect 'table_map' containing both the table itself, 
and possible any outer-refs if this was the last table in 
the subquery, was presented to make_cond_for_table().
      
As a pushed condition is only able to refer column from the table
the condition is pushed to, nothing else than columns from the
table itself (tab->table->map) may be refered in the pushed condition
constructed by 'push_cond= make_cond_for_table()'. 
      
Also fix a minor 'copy and paste' bug in a comment 
inside make_cond_for_table().

No testcase is possible on mainbranch as the NDB engine is not available (yet)
on mysql >= 5.5

Item_equal::val_int() checked for NULL-values by checking Item::null_value
*before* the respective ::store_value() and ::cmp(Item*) metods where called.

As Item::null_value is set by these metods, the value of 'null_value' 
is not valid until *after* ::store_value() or ::cmp() has
been called for the Item object.
      
Fix is to swap order of ::store_value()/::cmp() and checking of Item::null_value.
This pattern is widely used other places inside item_cmpfunc.cc .

other crashes

Some string manipulating SQL functions use a shared string object intended to
contain an immutable empty string. This object was used by the SQL function
SUBSTRING_INDEX() to return an empty string when one argument was of the wrong
datatype. If the string object was then modified by the sql function INSERT(),
undefined behavior ensued.

Fixed by instead modifying the string object representing the function's
result value whenever string manipulating SQL functions return an empty
string.

Relevant code has also been documented.

INVOKER-security view access check wrong" into mysql-5.5 tree.

Follow-up fix: mtr died if trying to run semisync test w/o the plugin

INVOKER-security view access check wrong".

When privilege checks were done for tables used from an 
INVOKER-security view which in its turn was used from 
a DEFINER-security view connection's active security
context was incorrectly used instead of security context
with privileges of the second view's creator.

This meant that users which had enough rights to access
the DEFINER-security view and as result were supposed to 
be able successfully access it were unable to do so in 
cases when they didn't have privileges on underlying tables 
of the INVOKER-security view.

This problem was caused by the fact that for INVOKER-security
views TABLE_LIST::security_ctx member for underlying tables
were set to 0 even in cases when particular view was used from 
another DEFINER-security view. This meant that when checks of
privileges on these underlying tables was done in
setup_tables_and_check_access() active connection security 
context was used instead of context corresponding to the 
creator of caller view.

This fix addresses the problem by ensuring that underlying
tables of an INVOKER-security view inherit security context
from the view and thus correct security context is used for
privilege checks on underlying tables in cases when such view 
is used from another view with DEFINER-security.

mysql-test/r/view_grant.result:
  Added coverage for various combinations of DEFINER and
  INVOKER-security views, including test for bug #58499
  "DEFINER-security view selecting from INVOKER-security
  view access check wrong".
mysql-test/t/view_grant.test:
  Added coverage for various combinations of DEFINER and
  INVOKER-security views, including test for bug #58499
  "DEFINER-security view selecting from INVOKER-security
  view access check wrong".
sql/sql_view.cc:
  When opening a non-suid view ensure that its underlying 
  tables will get the same security context as use for
  checking privileges on the view, i.e. security context
  of view invoker. This context can be different from the
  security context which is currently active for connection 
  in cases when this non-suid view is used from a view with
  suid security. Inheriting security context in such situation
  allows correctly apply privileges of creator of suid view
  in checks for tables of non-suid view (since in this 
  situation creator/definer of suid view serves as invoker
  for non-suid view).

        Item_func_spatial_collection::fix_length_and_dec didn't call parent's method, so
        the maybe_null was set to '0' after it. But in this case the result was
        just NULL, that caused wrong behaviour.

per-file comments:
  mysql-test/r/gis.result
Bug #57321 crashes and valgrind errors from spatial types 
        test result updated.

  mysql-test/t/gis.test
Bug #57321 crashes and valgrind errors from spatial types 
        test case added.
  sql/item_geofunc.h
Bug #57321 crashes and valgrind errors from spatial types 
        Item_func_geometry::fix_length_and_dec() called in
        Item_func_spatial_collection::fix_length_and_dec().

TIMESTAMP.

Item_cache::get_cache wasn't treating TIMESTAMP as a DATETIME value thus
returning string cache for items with TIMESTAMP type. This led to incorrect
TIMESTAMP -> INT conversion and to a wrong query result.

Fixed by using Item::is_datetime function to check for DATETIME type group.


mysql-test/r/type_timestamp.result:
  Added a test case for the bug#59330.
mysql-test/t/type_timestamp.test:
  Added a test case for the bug#59330.
sql/item.cc:
  Bug#59330: Incorrect result when comparing an aggregate function with
  TIMESTAMP.
  Item_cache::get_cache now uses is_datetime member function to detect DATETIME
  type group.

If the ::single_value_transformer() find an existing HAVING condition it used
to do the transformation:
            
  1) HAVING cond -> (HAVING Cond) AND (cond_guard (Item_ref_null_helper(...))
      
As the AND condition in 1) is Mc'Carty evaluated, the
right side of the AND cond should be executed only if the 
original 'HAVING evaluated' to true.
      
However, as we failed to set 'top_level' for the tranformed HAVING condition,
'abort_on_null' was FALSE after transformation. An
UNKNOWN having condition will then not terminate evaluation of the
transformed having condition, and we incorrectly continued
into the Item_ref_null_helper() part.

New patch, avoid global $opt_parallel
I still prefer not to print workerid when not doing parallel

tmptable needed

The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.

Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.

if max_allowed_packet >= 16M.

This bug was introduced by patch for bug#42503.

This patch restores behaviour that there was before patch
for bug#42503 was applied.

sql/net_serv.cc:
  Restored original right condition.

Local variable ds_warnings in run_query not cleared.
But when we call die() we don't have access to it.
Set global var. to point to it when allocated.

Test name spec would be cut at last /
Only do this when .test file name given, not suite.<test>

Followup: had forgotten to update mysqltest.test due to changed output - duh!

The problem from a user point of view was that on Solaris the
time related functions (e.g. NOW(), SYSDATE(), etc) would always
return a fixed time.

This bug was happening due to a logic in the time retrieving
wrapper function which would only call the time() function every
half second. This interval between calls would be calculated
using the gethrtime() and the logic relied on the fact that time
returned by it is monotonic.

Unfortunately, due to bugs in the gethrtime() implementation,
there are some cases where the time returned by it can drift
(See Solaris bug id 6600939), potentially causing the interval
calculation logic to fail.

The solution is to retrieve the correct time whenever a drift in
the time returned by gethrtime() is detected. That is, do not
use the cached time whenever the values (previous and current)
returned by gethrtime() are not monotonically increasing.

mysys/my_getsystime.c:
  Do not used the cached time if gethrtime is not monotonic.

Put descriptions of plugins into a separate file read by MTR
MTR itself has generalised code to read this and set env. variables
Removed the *SO variables, updated some tests accordingly
New commit: added optional list of plugin names for _LOAD variable
Also made changes for the new AUTH_* plugins

extended' to crash mysqld" (see http://lists.mysql.com/commits/128409).

to crash mysqld". 
      
handler::pushed_cond was not always properly reset when table objects where
recycled via the table cache.
      
handler::pushed_cond is now set to NULL in handler::ha_reset(). This should 
prevent pushed conditions from (incorrectly) re-apperaring in later queries.

Generalized fix for recursive backtick
Optional arg to eval_expr telling it not to interpret