Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 7AD4D2E01A6 for ; Tue, 4 Mar 2008 11:04:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 78484-08 for ; Tue, 4 Mar 2008 11:04:30 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by postgresql.org (Postfix) with ESMTP id AAB692E019B for ; Tue, 4 Mar 2008 11:04:38 -0400 (AST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOvzzEfLevdH/2dsb2JhbACBVpBomxo X-IronPort-AV: E=Sophos;i="4.25,444,1199626200"; d="scan'208";a="54768654" Received: from ppp247-71.static.internode.on.net (HELO DevBox.local) ([203.122.247.71]) by ipmail01.adl6.internode.on.net with ESMTP; 05 Mar 2008 01:34:34 +1030 Message-ID: <47CD6500.9030802@Sheeky.Biz> Date: Wed, 05 Mar 2008 01:34:32 +1030 From: Shane Ambler User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ivan Voras CC: pgsql-performance@postgresql.org Subject: Re: How to allocate 8 disks References: <1204285894.11773.33.camel@franck-gusty> <1204296705.11773.51.camel@franck-gusty> <47C88826.4040209@paradise.net.nz> <47C99B3E.4010606@emolecules.com> <20080301130347.0832b323@commandprompt.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/51 X-Sequence-Number: 29005 Ivan Voras wrote: > Joshua D. Drake wrote: > >> This scares me... You lose WAL you are a goner. Combine your OS and >> WAL into a RAID 1. > > Can someone elaborate on this? From the WAL concept and documentation at > http://www.postgresql.org/docs/8.3/interactive/wal-intro.html I'd say > the only data that should be lost are the transactions currently in the > log but not yet transferred to permanent storage (database files proper). > The log records what changes are made to your data files before the data files are changed. (and gets flushed to disk before the data files are changed) In the event of power loss right in the middle of the data files being updated for a transaction, when power is restored, how do we know what changes were made to which data files and which changes are incomplete? Without the log files there is no way to be sure your data files are not full of "half done transactions" Chances are that 90% of the time everything is fine but without the log files how do you check that your data files are as they should be. (or do you expect to restore from backup after any power outs?) Keeping them on a raid 1 gives you a level of redundancy to get you past hardware failures that happen at the wrong time. (as they all do) -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz