being logged to slow query log
The problem is that the execution time for a multi-statement
stored procedure as a whole may not be accurate, and thus not
be entered into the slow query log even if the total time
exceeds long_query_time. The reason for this is that
THD::utime_after_lock used for time calculation may be reset
at the start of each new statement, possibly leaving the total
SP execution equal to the time spent executing the last
statement in the SP.
This patch stores the utime on start of SP execution, and
restores it on exit of SP execution. A test is added.
assertion .\filesort.cc, line 797
A query with the "ORDER BY @@some_system_variable" clause,
where @@some_system_variable is NULL, causes assertion
failure in the filesort procedures.
The reason of the failure is in the value of
Item_func_get_system_var::maybe_null: it was unconditionally
set to false even if the value of a variable was NULL.
Revised the test to include a test of completion_type = 1 as well as making the test more readable / worthwhile
Removed the master.opt file as it was redundant / unnecessary.
conflicts:
Text conflict in mysql-test/suite/sys_vars/r/rpl_max_binlog_size_func.result
Text conflict in mysql-test/suite/sys_vars/t/rpl_max_binlog_size_func.test
