X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 9A1969DD569 for ; Tue, 21 Mar 2006 08:18:39 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 58949-02 for ; Tue, 21 Mar 2006 08:18:42 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 5901A9DD559 for ; Tue, 21 Mar 2006 08:18:37 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id C854F56437; Tue, 21 Mar 2006 06:18:40 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Tue, 21 Mar 2006 06:18:39 -0600 Date: Tue, 21 Mar 2006 06:18:39 -0600 From: "Jim C. Nasby" To: Csaba Nagy , Mikael Carneholm , postgres performance list Subject: Re: Migration study, step 1: bulk write performance Message-ID: <20060321121839.GT15742@pervasive.com> References: <7F10D26ECFA1FB458B89C5B4B0D72C2B088286@sesrv12.wirelesscar.com> <1142867952.16487.96.camel@coppola.muc.ecircle.de> <20060321112759.GF15742@pervasive.com> <1142941966.23597.4.camel@coppola.muc.ecircle.de> <20060321115618.GA12880@uio.no> <20060321120158.GO15742@pervasive.com> <20060321121032.GB12963@uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060321121032.GB12963@uio.no> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060321:nagy@ecircle-ag.com::EpKX+cr0cwy6oHBt:000000000000000000 0000000000000000000000003w8C X-Hashcash: 1:20:060321:mikael.carneholm@wirelesscar.com::ehMro9h5eKvjMJiT:00000 0000000000000000000000000W4j X-Hashcash: 1:20:060321:pgsql-performance@postgresql.org::QBoqdRZvOOrDHn5Q:00000 0000000000000000000000007705 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108] X-Spam-Score: 0.108 X-Spam-Level: X-Archive-Number: 200603/392 X-Sequence-Number: 17829 On Tue, Mar 21, 2006 at 01:10:32PM +0100, Steinar H. Gunderson wrote: > On Tue, Mar 21, 2006 at 06:01:58AM -0600, Jim C. Nasby wrote: > > Are you sure? Metadate changes are probably a lot more common on the WAL > > partition. In any case, I don't see why there should be a difference. > > The real issue is: is related filesystem metadata sync'd as part of a > > file being fsync'd? > > I've been told on this list that PostgreSQL actually takes care to fill a new > WAL file with zeroes etc. when initializing it; dig a few months back and I'm > sure it's there. That's fine and all, but does no good if the filesystem doesn't know that the file exists on a crash. The same concern is also true on the data partition, although it's less likely to be a problem because if you happen to crash soon after a DDL operation it's likely that you haven't had a checkpoint yet, so the operation will likely be repeated during WAL replay. But depending on that is a race condition. Basically, you need to know for certain that if PostgreSQL creates a file and then fsync's it that that file is safely on disk, and that the filesystem knows how to find it (ie: the metadata is also on disk in some fashion). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461