Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 5E414133798E for ; Wed, 5 Jan 2011 18:58:45 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 81129-08 for ; Wed, 5 Jan 2011 22:58:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 63.mail-out.ovh.net (63.mail-out.ovh.net [91.121.185.56]) by mail.postgresql.org (Postfix) with SMTP id B8F2713364DE for ; Wed, 5 Jan 2011 18:58:37 -0400 (AST) Received: (qmail 23230 invoked by uid 503); 5 Jan 2011 23:36:05 -0000 Received: from b6.ovh.net (HELO mail606.ha.ovh.net) (213.186.33.56) by 63.mail-out.ovh.net with SMTP; 5 Jan 2011 23:36:05 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 6 Jan 2011 00:58:33 +0200 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 6 Jan 2011 00:58:32 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Josh Berkus" , "Jeff Janes" Cc: pgsql-performance@postgresql.org Subject: Re: Wrong docs on wal_buffers? References: <4D24D7DE.6020507@agliodbs.com> Date: Wed, 05 Jan 2011 23:58:32 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.63 (Linux) X-Ovh-Tracer-Id: 17841009925814617703 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201101/24 X-Sequence-Number: 41811 > And the risks are rather asymmetric. I don't know of any problem from > too large a buffer until it starts crowding out shared_buffers, while > under-sizing leads to the rather drastic performance consequences of > AdvanceXLInsertBuffer having to wait on the WALWriteLock while holding > the WALInsertLock, Suppose you have a large update which generates lots of WAL, some WAL segment switching will take place, and therefore some fsync()s. If wal_buffers is small enough that it fills up during the time it takes to fsync() the previous WAL segment, isn't there a risk that all WAL writes are stopped, waiting for the end of this fsync() ?