X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 8A65911F626B for ; Wed, 29 Mar 2006 18:49:47 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 52694-02 for ; Wed, 29 Mar 2006 18:49:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtpout07-04.prod.mesa1.secureserver.net (smtpout07-01.prod.mesa1.secureserver.net [64.202.165.230]) by postgresql.org (Postfix) with SMTP id 36A9411F6268 for ; Wed, 29 Mar 2006 18:49:42 -0400 (AST) Received: (qmail 18697 invoked from network); 29 Mar 2006 22:49:42 -0000 Received: from unknown (69.199.39.70) by smtpout07-04.prod.mesa1.secureserver.net (64.202.165.233) with ESMTP; 29 Mar 2006 22:49:42 -0000 Message-ID: <442B0FC7.4040303@ummon.com> Date: Wed, 29 Mar 2006 17:52:55 -0500 From: stef User-Agent: Mozilla Thunderbird 1.0.7-4mdk (X11/20051221) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Lauzon CC: Richard Huxton , pgsql-performance@postgresql.org Subject: Re: Database possible corruption , unsolvable mystery References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.06 required=5 tests=[AWL=0.060] X-Spam-Score: 0.06 X-Spam-Level: X-Archive-Number: 200603/592 X-Sequence-Number: 18029 Eric Lauzon wrote: >Mabey later if this dosen't fix the problem , and as of information its >7.4.6 [i know its not the most rescent] >but it is the way it is right now and we suspect the problem might have >come from a power outage while there was >a full vacuum and the reason why its only one table that has been >affected is probably because it was the table being vacummed, >but this is only an assumption right now and more info will folow if the >problems persis after a full restore. > > > Hrm, you know that you -should- upgrade to at least the latest 7.4 (7.4.13 I think is the most recent). looking from the changelogs, there are a few bugs that you could be hitting; 7.4.10 * Fix race condition in transaction log management There was a narrow window in which an I/O operation could be initiated for the wrong page, leading to an Assert failure or data corruption. 7.4.9 * Improve checking for partially-written WAL pages * Fix error that allowed VACUUM to remove ctid chains too soon, and add more checking in code that follows ctid links. This fixes a long-standing problem that could cause crashes in very rare circumstances. 7.4.8 * Repair race condition between relation extension and VACUUMThis could theoretically have caused loss of a page's worth of freshly-inserted data, although the scenario seems of very low probability. There are no known cases of it having caused more than an Assert failure and these are only the ones that appear 'notably' in the changelog. In short, I -really- -would- -strongly- -advise- you upgrading to 7.4.13. Personally, I would have made this my first step, especially if your data is important. There is no need for a dump/reload between minor point releases. Although there is a security fix in 7.4.8. Since the db is in a state of 'down' or repair, why not do it now ? two birds, one stone. Regards Stef