Merge lp:~sergei.glushchenko/percona-server/5.5-slow-log-stored-procs into lp:percona-server/5.5
Status: | Merged |
---|---|
Approved by: | Laurynas Biveinis on 2014-12-02 |
Approved revision: | 699 |
Merged at revision: | 718 |
Proposed branch: | lp:~sergei.glushchenko/percona-server/5.5-slow-log-stored-procs |
Merge into: | lp:percona-server/5.5 |
Diff against target: |
277 lines (+112/-26) 6 files modified
mysql-test/r/percona_log_slow_sp_statements.result (+46/-10) mysql-test/t/percona_log_slow_sp_statements.test (+33/-5) sql/log.cc (+9/-0) sql/sp_head.cc (+0/-8) sql/sp_rcontext.h (+2/-3) sql/sql_parse.cc (+22/-0) |
To merge this branch: | bzr merge lp:~sergei.glushchenko/percona-server/5.5-slow-log-stored-procs |
Related bugs: | |
Related blueprints: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Laurynas Biveinis (community) | 2014-11-10 | Approve on 2014-12-02 | |
Review via email:
|
Description of the change
Implementation of log-slow-
When log_slow_
- Make an entry to slow-log for each query in stored procedures.
- Don't make an entry to slow-log for the CALL itself, because that
would count the time twice and skew reports.
- Slow-log entries are annotated with the stored procedure in
which it ran.
There is also issue 43131. Customer wants CALL statement not showed in slow log even if it takes long to execute, however individual queries inside stored procedure should be logged if they take long.
The part of this blueprint regarding bug #719386 has already been fixed.
http://
In all cases statement will look like
SELECT NAME_CONST(
But prepared CALL statement will be logged into slow log because it is SQLCOM_EXECUTE, not the SQLCOM_CALL. Not sure how to differentiate this case yet.
I made changes needed to recognize prepared statements which are CALL statements. Answer to the question posted in prev comment. Jenkins:
http://
- How are statements referencing procedure args logged? With var
names, values, or something else?
- Same question for the combination of stored procedures and
prepared statements (i.e. case 1: PREPARE s CALL p(@foo, 2);
EXECUTE s; case 2: PREPARE s CALL p(?, ?); EXECUTE s USING 1,
@foo; maybe case 3: PROCEDURE foo BEGIN EXECUTE bar;
- In the case of non-trivial answers, the above needs MTR
testing.