X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2484252E20 for ; Sat, 20 Aug 2005 11:40:50 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 90422-07 for ; Sat, 20 Aug 2005 14:40:41 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id E0C9352C63 for ; Sat, 20 Aug 2005 11:40:39 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7KEef86023045; Sat, 20 Aug 2005 10:40:44 -0400 (EDT) To: Michael Stone Cc: pgsql-performance@postgresql.org Subject: Re: extremly low memory usage In-reply-to: <20050820122305.GN19080@mathom.us> References: <1124386761.27881.119.camel@bluejay.goodinassociates.com> <4304CB77.4070403@arbash-meinel.com> <1124470109.27881.152.camel@bluejay.goodinassociates.com> <43061472.2080201@arbash-meinel.com> <6.2.3.4.0.20050819140714.05c181e8@pop.earthlink.net> <43063196.9000001@arbash-meinel.com> <1124485299.27881.192.camel@bluejay.goodinassociates.com> <43071162.6050405@kolumbus.fi> <20050820122305.GN19080@mathom.us> Comments: In-reply-to Michael Stone message dated "Sat, 20 Aug 2005 08:23:05 -0400" Date: Sat, 20 Aug 2005 10:40:41 -0400 Message-ID: <23044.1124548841@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200508/294 X-Sequence-Number: 14041 Michael Stone writes: > On Sat, Aug 20, 2005 at 02:17:54PM +0300, Marko Ristola wrote: >> Based on my knoledge, Ext3 is good with keeping filesystem integrity >> AND data integrity while pressing the reset button. However, by >> selecting data=writeback, you gain more speed, but you risk the data >> integrity during a crash: Ext3 garantees only filesystem integrity. > That's why postgres keeps its own transaction log. Any of these > filesystems guarantee data integrity for data that's been synced to > disk, and postgres keeps track of what data has and has not been > committed so it can recover gracefully from a failure. Right. I think the optimal setting for a Postgres data directory is journaled metadata, non-journaled file content. Postgres can take care of the data integrity for itself, but it does assume that the filesystem stays structurally sane (eg, data blocks don't get reassigned to the wrong file), so you need a filesystem guarantee about the metadata. WAL files are handled in a much more conservative way (created, filled with zeroes, and fsync'd before we ever put any valuable data in 'em). If you have WAL on its own drive then I think Mike's recommendation of no filesystem journalling at all for that drive is probably OK. Or you can do same as above (journal metadata only) if you want a little extra protection. And of course all this reasoning depends on the assumption that the drive tells the truth about write-completion. If the drive does write caching it had better be able to complete all its accepted writes before dying in a power failure. (Hence, battery-backed write cache is OK, any other kind is evil.) regards, tom lane