X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id CB23B9FB31B for ; Wed, 16 Aug 2006 00:02:27 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 49415-02 for ; Wed, 16 Aug 2006 00:02:14 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id A55D39FB32D for ; Wed, 16 Aug 2006 00:02:12 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k7G30sZv028556; Tue, 15 Aug 2006 23:00:54 -0400 (EDT) To: "Steinar H. Gunderson" cc: pgsql-performance@postgresql.org Subject: Re: Postgresql Performance on an HP DL385 and In-reply-to: <20060815222323.GA18180@uio.no> References: <20060814170545.GG27928@pervasive.com> <20060814170902.GN2900@mathom.us> <20060815162926.GS27928@pervasive.com> <20060815172645.GU2900@mathom.us> <20060815183327.GC12834@mark.mielke.cc> <20060815190254.GW2900@mathom.us> <20060815193951.GA13695@mark.mielke.cc> <20060815205857.GY2900@mathom.us> <20060815213842.GA15210@mark.mielke.cc> <20060815222024.GV21363@pervasive.com> <20060815222323.GA18180@uio.no> Comments: In-reply-to "Steinar H. Gunderson" message dated "Wed, 16 Aug 2006 00:23:23 +0200" Date: Tue, 15 Aug 2006 23:00:54 -0400 Message-ID: <28555.1155697254@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.185 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/259 X-Sequence-Number: 20444 "Steinar H. Gunderson" writes: > On Tue, Aug 15, 2006 at 05:20:25PM -0500, Jim C. Nasby wrote: >> This is only valid if the pre-allocation is also fsync'd *and* fsync >> ensures that both the metadata and file data are on disk. Anyone >> actually checked that? :) > fsync() does that, yes. fdatasync() (if it exists), OTOH, doesn't sync the > metadata. Well, the POSIX spec says that fsync should do that ;-) My guess is that most/all kernel filesystem layers do indeed try to sync everything that the spec says they should. The Achilles' heel of the whole business is disk drives that lie about write completion. The kernel is just as vulnerable to that as any application ... regards, tom lane