Re: Asynchronous commit | Transaction loss at server crash - Mailing list pgsql-admin

From Scott Marlowe
Subject Re: Asynchronous commit | Transaction loss at server crash
Date
Msg-id AANLkTik9NzZogI7Sy1-IY-fqDjWF3wWX3jCijoPikwuL@mail.gmail.com
Whole thread Raw
In response to Re: Asynchronous commit | Transaction loss at server crash  (Balkrishna Sharma <b_ki@hotmail.com>)
List pgsql-admin
On Thu, May 20, 2010 at 2:26 PM, Balkrishna Sharma <b_ki@hotmail.com> 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 ?
> Thanks for your inputs.

Not at present.  The write cache in an SSD cannot be disabled, because
it has to aggregate a bunch of writes together.  So, it reads say
128k, changes x % then writes it back out.  During this period, power
loss could result in those writes being lost.  However, the SSD will
have reported success already.  There are some that supposedly have a
big enough capacitor to complete this write cache, but I have seen no
definitive tests with pgsql that this actually works to keep your data
safe in event of power loss during write.

A battery backed caching RAID controller CAN be depended on, because
they have been tested and shown to do the right thing.

pgsql-admin by date:

Previous
From: Balkrishna Sharma
Date:
Subject: Re: Asynchronous commit | Transaction loss at server crash
Next
From: Jesper Krogh
Date:
Subject: Re: Asynchronous commit | Transaction loss at server crash