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 BC56D9FB274 for ; Tue, 15 Aug 2006 17:05:31 -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 16310-01 for ; Tue, 15 Aug 2006 17:05:21 -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 053C99FB235 for ; Tue, 15 Aug 2006 17:05:21 -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 k7FK5H2d019784; Tue, 15 Aug 2006 16:05:17 -0400 (EDT) To: mark@mark.mielke.cc cc: "Jim C. Nasby" , Steve Poe , pgsql-performance@postgresql.org Subject: Re: Postgresql Performance on an HP DL385 and In-reply-to: <20060815183147.GB12834@mark.mielke.cc> References: <3E37B936B592014B978C4415F90D662D03FFEF6E@MI8NYCMAIL06.Mi8.com> <721b21dc0608082245u6ee62e7dg522ff18e4d72683@mail.gmail.com> <20060809210539.GR40481@pervasive.com> <1155180553.13315.0.camel@amd64-gentoo-laptop> <20060810110935.GF2900@mathom.us> <20060814153841.GF27928@pervasive.com> <721b21dc0608140851v2332cdf9g59808004c983540f@mail.gmail.com> <20060814170545.GG27928@pervasive.com> <20060814170902.GN2900@mathom.us> <20060815162926.GS27928@pervasive.com> <20060815183147.GB12834@mark.mielke.cc> Comments: In-reply-to mark@mark.mielke.cc message dated "Tue, 15 Aug 2006 14:31:48 -0400" Date: Tue, 15 Aug 2006 16:05:17 -0400 Message-ID: <19783.1155672317@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.186 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/245 X-Sequence-Number: 20430 mark@mark.mielke.cc writes: > I've been worrying about this myself, and my current conclusion is that > ext2 is bad because: a) fsck, and b) data can be lost or corrupted, which > could lead to the need to trash the xlog. > Even ext3 in writeback mode allows for the indirect blocks to be updated > without the data underneath, allowing for blocks to point to random data, > or worse, previous apparently sane data (especially if the data is from > a drive only used for xlog - the chance is high that a block might look > partially valid?). At least for xlog, this worrying is misguided, because we zero and fsync a WAL file before we ever put any valuable data into it. Unless the filesystem is lying through its teeth about having done an fsync, there should be no metadata changes happening for an active WAL file (other than mtime of course). regards, tom lane