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 354609DC84A for ; Tue, 21 Mar 2006 08:45:26 -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 60830-10 for ; Tue, 21 Mar 2006 08:45:28 -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 88FBB9DC80D for ; Tue, 21 Mar 2006 08:45:23 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id E055C56427; Tue, 21 Mar 2006 06:45:26 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Tue, 21 Mar 2006 06:45:25 -0600 Date: Tue, 21 Mar 2006 06:45:25 -0600 From: "Jim C. Nasby" To: pgsql-performance@postgresql.org Subject: Re: Migration study, step 1: bulk write performance Message-ID: <20060321124525.GX15742@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> <20060321121839.GT15742@pervasive.com> <20060321122954.GB13241@uio.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060321122954.GB13241@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:pgsql-performance@postgresql.org::UOrw63lUoKHB4bI3:00000 000000000000000000000000Kesu 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/397 X-Sequence-Number: 17834 On Tue, Mar 21, 2006 at 01:29:54PM +0100, Steinar H. Gunderson wrote: > On Tue, Mar 21, 2006 at 06:18:39AM -0600, Jim C. Nasby wrote: > > 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). > > It seems to do, quoting Tom from > http://archives.postgresql.org/pgsql-performance/2005-11/msg00184.php: 404 :( > > == snip == > its metadata is not changing. As long as the filesystem follows > the minimal rule of syncing metadata about a file when it fsyncs the > file, all the live WAL files should survive crashes OK. And therin lies the rub: file metadata *must* commit to disk as part of an fsync, and it's needed for both WAL and heap data. It's needed for heap data because as soon as a checkpoint completes, PostgreSQL is free to erase any WAL info about previous DDL changes. On FreeBSD, if you're using softupdates, the filesystem will properly order writes to the drive so that metadata must be written before file data; this ensures that an fsync on the file will first write any metadata before writing the data itself. With fsync turned off, any metadata-changing commands will wait for the metadata to commit to disk before returning (unless you run async...) I'm not really sure how this all plays out on a journalling filesystem. -- 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