artifact_id;status_id;status_name;priority;submitter_id;submitter_name;assigned_to_id;assigned_to_name;open_date;close_date;last_modified_date;summary;details;"Category";"Group";"Resolution"
1006256;1;"Open";3;102516;"Koen Martens";101537;"Guillaume Smet";"2007-06-12 16:23";"";"2012-09-24 02:14";"Add support for fastpath function calls";"This patch adds support for fastpath function calls, such as the lo_* functions that are used to access large objects.";"None";"None";"None"
1008506;1;"Open";3;100;"Nobody";101537;"Guillaume Smet";"2007-08-24 10:16";"";"2012-09-24 02:14";"Timestamps in stderr logs not parsed";"Timestamps in PostgreSQL stderr logs are in format YYYY-MM-DD HH:MI:SS. pgFouine feeds this to strtotime(), which fails to recognize.

I changed include/postgresql/parsers/StderrPostgreSQLParser.class.php from this:

$timestamp = strtotime($formattedDate);

to this:

list($date, $time) = explode(' ', $formattedDate);
list($year, $month, $day) = explode('-', $date);
list($hour, $minute, $second) = explode(':', $time);
$timestamp = mktime($hour, $minute, $second, $month, $day, $year);

As a result times are correct now in reports.";"None";"None";"None"
1010944;1;"Open";3;190972;"Matt Saunders";100;"Nobody";"2010-11-16 16:41";"";"2012-09-24 02:14";"postgresql 9.0 csvlogs have an extra field ";"Hi Guillaume,

Per http://www.postgresql.org/docs/9.0/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG , Postgres 9.0 adds an extra field named ""application_name"" to the end of each CSV line.

pgfouine cannot parse these currently.

Here is a brief patch to address this problem.  It's not very pretty, nor does it make any attempt to process the new application_name information, but it does allow pgfouine to successfully analyse the logs from our 9.0 servers.

Hope this is useful!


Matt.



--- ./include/CsvlogLogReader.class.php.prematts        2010-11-16 07:54:38.000000000 -0800
+++ ./include/CsvlogLogReader.class.php 2010-11-16 07:55:25.000000000 -0800
@@ -32,7 +32,7 @@
                while ($csvLine = fgetcsv($filePointer)) {
                        $lineParsedCounter ++;

-                       if(count($csvLine) == 22) {
+                       if((count($csvLine) == 22) || (count($csvLine) == 23)) {
                                $lines =& $lineParser->parse($csvLine);

                                if($lines) {
@@ -59,4 +59,4 @@
        }
 }
";"None";"None";"None"
1010963;1;"Open";3;105922;"Gurjeet Singh";100;"Nobody";"2010-12-16 17:36";"";"2012-09-24 02:14";"Add option to exclude INSERT statements";"This is a quick and dirty patch to exclude INSERT statements from log analysis.

I was analyzing a postgres stderr log file of size 388 MB and about 2.8 million lines and PHP kept erroring out with the error 

Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)...

Majority of INSERT statemets (probably all of them) were huge multi-row INSERTs which I was not interested in any way.

Probably a cleaner approach would have been to exclude only multi-row statements, but I am not too familiar with object oriented PHP to fix the script to that level.

I hope it makes it into pgFouine in some form or the other.

Regards,
";"None";"None";"None"
1011132;1;"Open";3;433318;"Guillaume Luchet";100;"Nobody";"2011-12-09 14:43";"";"2012-09-24 02:14";"-onlypattern feature";"I've just added the -onlypattern option allowing to ignore all queries but thoses matching a pattern.

I frequently need stats on only some defined queries, so I add at the beginning of the query something like ""/* KEYWORD */ SELECT blah...""

After this I can run pgfouine to get only report on those queries

./pgfouine.php -file /var/log/syslog -onlypattern ""/^\/\* KEYWORD/"" > output.html";"None";"None";"None"