Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 8843D1337B34 for ; Tue, 16 Nov 2010 21:12:41 -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 42160-03 for ; Wed, 17 Nov 2010 01:12:35 +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 204DE1335B36 for ; Tue, 16 Nov 2010 21:12:34 -0400 (AST) Received: by mail.anarazel.de (Postfix, from userid 108) id F3C6E448007; Wed, 17 Nov 2010 02:12:33 +0100 (CET) Received: from anarazel.de (f053044066.adsl.alicedsl.de [78.53.44.66]) by mail.anarazel.de (Postfix) with ESMTPSA id B76CF448006; Wed, 17 Nov 2010 02:12:30 +0100 (CET) Received: by anarazel.de (Postfix, from userid 1000) id 331001C0113; Wed, 17 Nov 2010 02:12:30 +0100 (CET) From: Andres Freund To: Tom Lane Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? Date: Wed, 17 Nov 2010 02:12:29 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37-rc1-andres-00542-g0143832; KDE/4.5.1; x86_64; ; ) Cc: pgsql-performance@postgresql.org, Josh Berkus , Greg Smith References: <201011170201.24782.andres@anarazel.de> <11113.1289955868@sss.pgh.pa.us> In-Reply-To: <11113.1289955868@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011170212.30033.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/277 X-Sequence-Number: 41301 On Wednesday 17 November 2010 02:04:28 Tom Lane wrote: > Andres Freund writes: > > On Wednesday 17 November 2010 01:51:28 Tom Lane wrote: > >> Well, there's a forced fsync after writing the last page of an xlog > >> file, but I don't believe that proves that more than 16MB of xlog > >> buffers is useless. Other processes could still be busy filling the > >> buffers. > > > > Maybe I am missing something, but I think the relevant > > AdvanceXLInsertBuffer() is currently called with WALInsertLock held? > > The fsync is associated with the write, which is not done with insert > lock held. We're not quite that dumb. Ah, I see. The XLogWrite in AdvanceXLInsertBuffer is only happening if the head of the buffer gets to the tail - which is more likely if the wal buffers are small... Andres