Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id D5D9C6327D4 for ; Wed, 18 Aug 2010 15:49:32 -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 15195-05 for ; Wed, 18 Aug 2010 18:49:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from glacier.frostconsultingllc.com (glacier.frostconsultingllc.com [69.36.227.170]) by mail.postgresql.org (Postfix) with ESMTP id 5BB2C63243E for ; Wed, 18 Aug 2010 15:49:24 -0300 (ADT) Received: from dsl081-245-111.sfo1.dsl.speakeasy.net ([64.81.245.111] helo=Sidney-Stratton.local) by glacier.frostconsultingllc.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1OlnhM-0006PT-A3; Wed, 18 Aug 2010 11:49:23 -0700 Message-ID: <4C6C2B2B.9060501@agliodbs.com> Date: Wed, 18 Aug 2010 11:49:15 -0700 From: Josh Berkus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Tom Lane CC: PostgreSQL-development Subject: Re: Return of the Solaris vacuum polling problem -- anyone remember this? References: <4C69827A.409@agliodbs.com> <19969.1281986537@sss.pgh.pa.us> In-Reply-To: <19969.1281986537@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201008/1319 X-Sequence-Number: 168122 > What I find interesting about that trace is the large proportion of > writes. That appears to me to indicate that it's *not* a matter of > vacuum delays, or at least not just a matter of that. The process seems > to be getting involved in having to dump dirty buffers to disk. Perhaps > the background writer is malfunctioning? You appear to be correct in that it's write-related. Will be testing on what specificially is producing it. Note that this is one of two ostensibly duplicate servers, and the issue has never appeared on the other server. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com