Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id E24F61337B67 for ; Tue, 16 Nov 2010 20:30:26 -0400 (AST) 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 30617-01 for ; Wed, 17 Nov 2010 00:30:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.anarazel.de (mail.anarazel.de [217.115.131.40]) by mail.postgresql.org (Postfix) with ESMTP id C50601337B64 for ; Tue, 16 Nov 2010 20:30:18 -0400 (AST) Received: by mail.anarazel.de (Postfix, from userid 108) id D32B0448005; Wed, 17 Nov 2010 01:30:17 +0100 (CET) Received: from anarazel.de (f053044066.adsl.alicedsl.de [78.53.44.66]) by mail.anarazel.de (Postfix) with ESMTPSA id 263C8448003; Wed, 17 Nov 2010 01:30:11 +0100 (CET) Received: by anarazel.de (Postfix, from userid 1000) id 01D2C1C0113; Wed, 17 Nov 2010 01:30:10 +0100 (CET) From: Andres Freund To: pgsql-performance@postgresql.org Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Date: Wed, 17 Nov 2010 01:30:09 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37-rc1-andres-00542-g0143832; KDE/4.5.1; x86_64; ; ) Cc: Tom Lane , Josh Berkus , Greg Smith References: <4CE312D9.6030503@agliodbs.com> <9058.1289950294@sss.pgh.pa.us> In-Reply-To: <9058.1289950294@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011170130.10720.andres@anarazel.de> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201011/273 X-Sequence-Number: 41297 On Wednesday 17 November 2010 00:31:34 Tom Lane wrote: > Josh Berkus writes: > > On 11/16/10 12:39 PM, Greg Smith wrote: > >> I want to next go through and replicate some of the actual database > >> level tests before giving a full opinion on whether this data proves > >> it's worth changing the wal_sync_method detection. So far I'm torn > >> between whether that's the right approach, or if we should just increase > >> the default value for wal_buffers to something more reasonable. > > > > We'd love to, but wal_buffers uses sysV shmem. > > Well, we're not going to increase the default to gigabytes Especially not as I don't think it will have any effect after wal_segment_size as that will force a write-out anyway. Or am I misremembering the implementation? Andres