Re: Asynchronous commit | Transaction loss at server crash

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Asynchronous commit | Transaction loss at server crash
Дата
Msg-id AANLkTik9NzZogI7Sy1-IY-fqDjWF3wWX3jCijoPikwuL@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Asynchronous commit | Transaction loss at server crash  (Balkrishna Sharma <b_ki@hotmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Balkrishna Sharma
Дата:
Сообщение: Re: Asynchronous commit | Transaction loss at server crash
Следующее
От: Jesper Krogh
Дата:
Сообщение: Re: Asynchronous commit | Transaction loss at server crash