Received: from maia.hub.org (maia-4.hub.org [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 33EEE632F24 for ; Thu, 20 May 2010 17:34:09 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 71662-05 for ; Thu, 20 May 2010 20:34:02 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from shrek.krogh.cc (2605ds1-ynoe.0.fullrate.dk [90.184.12.24]) by mail.postgresql.org (Postfix) with ESMTP id D44B4632693 for ; Thu, 20 May 2010 17:34:01 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by shrek.krogh.cc (Postfix) with ESMTP id 988F4326C4E; Thu, 20 May 2010 22:33:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at shrek.krogh.cc Received: from shrek.krogh.cc ([127.0.0.1]) by localhost (shrek.krogh.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjtZE9ebaqQM; Thu, 20 May 2010 22:33:49 +0200 (CEST) Received: from [90.184.13.151] (2605ds1-ynoe.2.fullrate.dk [90.184.13.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jesper@krogh.cc) by shrek.krogh.cc (Postfix) with ESMTPSA id 9BADC3271C4; Thu, 20 May 2010 22:33:49 +0200 (CEST) Message-ID: <4BF59CAC.9040200@krogh.cc> Date: Thu, 20 May 2010 22:33:48 +0200 From: Jesper Krogh User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Balkrishna Sharma CC: scott.marlowe@gmail.com, pgsql-admin@postgresql.org Subject: Re: Asynchronous commit | Transaction loss at server crash References: , , , 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-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201005/204 X-Sequence-Number: 34677 On 2010-05-20 22:26, Balkrishna Sharma wrote: > But if we have write-through setting, failure before the cache can write to disk will result in incomplete transaction (i.e. host will know that the transaction was incomplete). Right > > Two things I need for my system is:1. Unsuccessful transactions with a notification back that it is unsuccessful is ok but telling it is a successful transaction and not being able to write to database is not acceptable (ever).2. My write time (random access time) should be as minimal as possible. > Can a SSD with write-thru cache achieve this > A Battery Backed raid controller is not that expensive. (in the range of 1 or 2 SSD disks). And it is (more or less) a silverbullet to the task you describe. SSD "might" solve the problem, but comes with a huge range of unknowns at the moment. * Wear over time. * Degraded performance in write-through mode. * Degrading peformance over time. * Writeback mode not robust to power-failures. Plugging your system (SSD's) with an UPS and trusting it fully could solve most of the problems (running in writeback mode). But compared in complexity, I would say that the Battery backed raid controller is way more easy to get right. ... if you had a huge dataset you were doing random reads into and couldn't beef your system with more memory(cheapy) SSD's might be a good solution for that. -- Jesper