Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 4A422650390 for ; Tue, 4 Nov 2008 14:48:38 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 89211-04-4 for ; Tue, 4 Nov 2008 14:48:37 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mail.postgresql.org (Postfix) with ESMTP id E9B5C65039F for ; Tue, 4 Nov 2008 14:48:36 -0400 (AST) Received: by wa-out-1112.google.com with SMTP id j4so1784526wah.19 for ; Tue, 04 Nov 2008 10:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=P0XZ7jkKn9t4+4xi7tCOEsaW0tJ7D+fjPvTTLhl+31o=; b=aUnJC4Q3lTCNfhfv1K2sDwlAIjrBSlJ2/90uTe9dbLuJqxoCR85yXabaGfQftubsdu Xmg36wfGPNZz028yjQMvy/NnGIYfEOllUFlnLl9peV2WvVPh+Xoq6YjWtkF6ZoiXDmW/ 7GBUnIXK9BdJSIi88f1WbCGJXhIWa/QICM+1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Ss7hP6fCvaiFloiVIYwai08WRHvLU8M29NjHZUotKdeLKurYqnLKMAZbNwYoR5IjSX qOS15AOFLVpgfCabh1/V9zjxyQcj5uTd6h/rsF8Ye4sJdU1RrsGj64ZWYn1P+CdLn6J6 RYNfVwJ+uJ66q/qptpzbPDh4shdCtH34IdFRc= Received: by 10.115.60.1 with SMTP id n1mr1126133wak.179.1225824515614; Tue, 04 Nov 2008 10:48:35 -0800 (PST) Received: by 10.114.39.11 with HTTP; Tue, 4 Nov 2008 10:48:35 -0800 (PST) Message-ID: Date: Tue, 4 Nov 2008 11:48:35 -0700 From: "Scott Marlowe" To: "Tom Lane" Subject: Re: rebellious postgres process Cc: "Laszlo Nagy" , pgsql-admin@postgresql.org In-Reply-To: <25929.1225824360@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490FFCF4.2050500@shopzeus.com> <16117.1225804625@sss.pgh.pa.us> <49106ED5.10805@shopzeus.com> <25929.1225824360@sss.pgh.pa.us> X-Archive-Number: 200811/28 X-Sequence-Number: 30682 On Tue, Nov 4, 2008 at 11:46 AM, Tom Lane wrote: > "Scott Marlowe" writes: >> On Tue, Nov 4, 2008 at 8:48 AM, Laszlo Nagy wrote: >>> The server was rebooting intermittently, so we replaced the RAM (we got a >>> kernel page fault). But it was a week ago. The server is now stable. But is >>> it possible that somehow the file system became inconsistent, and that is >>> causing an infinite loop in the stats collector? Just guessing. > >> Yes, you really can't trust any data that was written to the drives >> while the bad memory was in place. > > Still, it's quite unclear how bad data read from the stats file could > have led to an infinite loop. The stats file format is pretty "flat" > and AFAICS the worst effect of undetected corruption would be to have > wrong count values for some tables/databases. True. Is it possible some other bit of the data in the system was corrupted and freaking out the stats collector?