Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id AA2476326E8 for ; Sun, 14 Feb 2010 13:11:55 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 59759-08 for ; Sun, 14 Feb 2010 17:11:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id F296F63256D for ; Sun, 14 Feb 2010 13:11:44 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o1EHBdjN022296; Sun, 14 Feb 2010 12:11:40 -0500 (EST) To: Greg Stark cc: Robert Haas , Andres Freund , pgsql-hackers@postgresql.org Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) In-reply-to: <407d949e1002140731j85a4f97nc053ec1b0f3cc458@mail.gmail.com> References: <4427a97a0912101235x3ade510blcc00d5ce9883c6b6@mail.gmail.com> <20100208030901.GA7407@alvh.no-ip.org> <603c8f071002072053w16897addtd52fcc4cf880df53@mail.gmail.com> <201002110327.35810.andres@anarazel.de> <603c8f071002120749o6a2e9e54h5cf21dc91d1790b9@mail.gmail.com> <407d949e1002140603v1c7515d7t697568a3865ac6fe@mail.gmail.com> <407d949e1002140731j85a4f97nc053ec1b0f3cc458@mail.gmail.com> Comments: In-reply-to Greg Stark message dated "Sun, 14 Feb 2010 15:31:58 +0000" Date: Sun, 14 Feb 2010 12:11:39 -0500 Message-ID: <22295.1266167499@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.722 tagged_above=-10 required=5 tests=AWL=-0.612, BAYES_05=-1.11 X-Spam-Level: X-Archive-Number: 201002/1141 X-Sequence-Number: 157484 Greg Stark writes: > So I think we have a bigger problem than just copydir.c. It seems to > me we should be fsyncing the table space data directories on every > checkpoint. Is there any evidence that anyone anywhere has ever lost data because of a lack of directory fsyncs? I sure don't recall any bug reports that seem to match that theory. It seems to me that we're talking about a huge hit in both code complexity and performance to deal with a problem that doesn't actually occur in the field; and which furthermore is trivially solved on any modern filesystem by choosing the right filesystem options. Why don't we just document those options, instead? regards, tom lane