Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 34DB99FB3DF for ; Fri, 1 Jun 2007 18:25:34 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 67356-03-2 for ; Fri, 1 Jun 2007 18:25:26 -0300 (ADT) X-Greylist: delayed 00:05:00.866018 by SQLgrey-1.7.5 Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.200.83]) by postgresql.org (Postfix) with ESMTP id DCA9D9FB2F9 for ; Fri, 1 Jun 2007 18:25:29 -0300 (ADT) Received: from [10.1.2.2] (c-75-71-235-22.hsd1.co.comcast.net[75.71.235.22]) by comcast.net (sccrmhc13) with ESMTP id <2007060121202601300ivuhte>; Fri, 1 Jun 2007 21:20:27 +0000 From: "Ed L." To: "George Pavlov" Subject: Re: query log corrupted-looking entries Date: Fri, 1 Jun 2007 15:20:19 -0600 User-Agent: KMail/1.9.5 Cc: pgsql-general@postgresql.org References: <29860.1161202644@sss.pgh.pa.us> <200705291119.55567.pgsql@bluepolka.net> <8C5B026B51B6854CBE88121DBF097A86CDD9A4@ehost010-33.exch010.intermedia.net> In-Reply-To: <8C5B026B51B6854CBE88121DBF097A86CDD9A4@ehost010-33.exch010.intermedia.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706011520.19227.pgsql@bluepolka.net> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/135 X-Sequence-Number: 114958 On Friday 01 June 2007 3:09 pm, George Pavlov wrote: > On 5/29/2007 10:19 AM, Ed L. wrote: > > On Wednesday 23 May 2007 1:04 pm, George Pavlov wrote: > > FWIW, I've also been seeing this sort of query log > > corruption for as long as I can remember, 7.1 through 8.2, > > HPUX (parisc, ia64), Linux on intel, amd... > > Do you have any tricks for dealing with the problem from a > query analyzer perspective? That is, if you use something like > pgfouine do you have any quick and easy way to remove those > lines (and the affected lines around them)? Or someway to > "fix" the corrupted lines? I'd say that lately ~40% of my > daily query logs are suffering from this problem making query > analysis very hard. Not really. I filter by perl regular expressions, but I wouldn't say that is reliable. However, our query volumes are high enough that losing a few here and there is no big deal in analysis. I long ago realized that reliably replaying query logs was infeasible due in part to this issue. Regex filtering is problematic and error-prone (for example, how do you reliably tell the difference between log timestamp and DB data?). Perhaps others have better answers. Ed