Logging slow stored procedures caused the slow log to write
very large lock times. The lock times was a result of a
negative number being cast to an unsigned integer.
The reason the lock time appeard negative was because
one of the measurements points was reset after execution
causing it to change order with the start time of the
statement.
This bug is related to bug 47905 which in turn was
introduced because of a joint fix for 12480,12481,12482 and 11587.
The fix is to only reset the start_time before any statement
execution in a SP while not resetting start_utime or
utime_after_lock which are used for measuring the
performance of the SP. Start_time is used to set the
timestamp on the replication event which controlls how
the slave interprets time functions like NOW().
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.
mysql-test/suite/sys_vars/r/slow_query_log_func.result:
New test results for #47905.
mysql-test/suite/sys_vars/t/slow_query_log_func.test:
New test case for #47905.
sql/sp_head.cc:
Save and restore the THD::utime_after_lock on entry and
exit of execute_procedure().
