Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 1BB47632B87 for ; Wed, 7 Jul 2010 05:58:48 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 70811-05 for ; Wed, 7 Jul 2010 08:58:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.catalyst.net.nz (bertrand.catalyst.net.nz [202.78.240.40]) by mail.postgresql.org (Postfix) with ESMTP id 84EB46329A2 for ; Wed, 7 Jul 2010 05:58:40 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.catalyst.net.nz (Postfix) with ESMTP id D45A733A79 for ; Wed, 7 Jul 2010 20:58:36 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz Received: from mail.catalyst.net.nz ([127.0.0.1]) by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwrdA3IWUq3R for ; Wed, 7 Jul 2010 20:58:36 +1200 (NZST) Received: from [192.168.1.64] (122-58-208-29.jetstream.xtra.co.nz [122.58.208.29]) (Authenticated sender: mark.kirkwood) by mail.catalyst.net.nz (Postfix) with ESMTPSA id 7543B33803 for ; Wed, 7 Jul 2010 20:58:36 +1200 (NZST) Message-ID: <4C3441BB.5020103@catalyst.net.nz> Date: Wed, 07 Jul 2010 20:58:35 +1200 From: Mark Kirkwood User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: pgsql-performance Subject: Re: [Slony1-general] WAL partition overloaded--by autovacuum? References: <03D2C5F0-F222-4088-B5E4-8DA688565B70@iparadigms.com> In-Reply-To: <03D2C5F0-F222-4088-B5E4-8DA688565B70@iparadigms.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.79 tagged_above=-10 required=5 tests=BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201007/82 X-Sequence-Number: 39471 On 07/07/10 13:10, Richard Yen wrote: > > This leads me to believe that there was a sudden flurry of write activity that occurred, and the process that would flush WAL files to /db/data/ couldn't keep up, thereby filling up the disk. I'm wondering if anyone else out there might be able to give me some insight or comments to my assessment--is it accurate? Any input would be helpful, and I'll try to make necessary architectural changes to keep this from happening again. > Do you have wal archiving enabled? (if so lets see your archive_command). Cheers Mark