pt-query-digest with custom --group-by throws error
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Toolkit moved to https://jira.percona.com/projects/PT |
Fix Released
|
Medium
|
Brian Fraser |
Bug Description
See the attached file. I've just written a filter to extract the "page number" from an embedded comment, and custom group-by it. Here is the filter, which I've placed into 'pages.pl' :
use strict;
use warnings FATAL => 'all';
use Data::Dumper;
my $page = 0;
if ( $event->{arg} ) {
($page) = $event->{arg} =~ m#/\*page_
}
$event->{page} = ($page || 0);
1
If I run this command:
$ pt-query-digest --filter pages.pl --group-by=page sample.log
The result is an infinite loop: pt-query-digest just prints out the following forever:
# 1.6s user time, 520ms system time, 17.32M rss, 2.34G vsz
# Current date: Fri Mar 16 17:25:56 2012
# Hostname: Barons-iMac.local
# Files: sample.log
# Overall: 7 total, 4 unique, 0 QPS, 0x concurrency _______
# Time range: all events occurred at 2012-03-15 18:01:58
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 10ms 0 3ms 1ms 3ms 1ms 1ms
# Lock time 0 0 0 0 0 0 0
# Rows sent 0 0 0 0 0 0 0
# Rows examine 0 0 0 0 0 0 0
# Query size 667 27 243 95.29 234.30 79.20 28.75
Pipeline process 4 (iteration) caused an error: I need a where argument at /Users/
Now, if I change the $event->{page} to be a string instead of an integer, like this:
use strict;
use warnings FATAL => 'all';
use Data::Dumper;
my $page = '';
if ( $event->{arg} ) {
($page) = $event->{arg} =~ m#/\*(page_
}
$event->{page} = ($page || 'no page defined');
1
the tool produces a report that's grouped by 'page' as I expect.
Related branches
- Brian Fraser (community): Approve
-
Diff: 136 lines (+122/-0)3 files modifiedt/pt-query-digest/bugs.t (+55/-0)
t/pt-query-digest/samples/bug_957442_filter.pl (+9/-0)
t/pt-query-digest/samples/bug_957442_sample.log (+58/-0)
Changed in percona-toolkit: | |
milestone: | none → 2.1.7 |
Changed in percona-toolkit: | |
status: | In Progress → Fix Committed |
Changed in percona-toolkit: | |
milestone: | 2.1.7 → 2.1.8 |
Changed in percona-toolkit: | |
status: | Fix Committed → Fix Released |
Hm. I can't seem able to reproduce this in 2.1.5. Maybe it was fixed along the way? I'm pushing a branch that at least adds a regression fix, so we don't inadvertently break this again.