From: Balkrishna Sharma <b_ki@hotmail.com>
To: scott.marlowe@gmail.com
Cc: pgsql-admin@postgresql.org
Subject: Re: Asynchronous commit | Transaction loss at server crash
Date: Thu, 20 May 2010 16:26:42 -0400
Message-ID: <BAY149-w464B3415293316B1A6739AF0E30@phx.gbl> (raw)
In-Reply-To: <AANLkTinT3Tx3nNb4YME6j58Edp45Q9pgCyVRkZYTnXU1@mail.gmail.com>
References: <BAY149-w7E2586A2E044680536BD8F0E30@phx.gbl>
<AANLkTimxy4_ecy3MnHYTNeWcVOrIQdJIm1_nutxHEBd4@mail.gmail.com>
<BAY149-w47C0EFBE3720C0DA258E4AF0E30@phx.gbl>
<AANLkTinT3Tx3nNb4YME6j58Edp45Q9pgCyVRkZYTnXU1@mail.gmail.com>
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.
> Date: Thu, 20 May 2010 14:12:33 -0600
> Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server crash
> From: scott.marlowe@gmail.com
> To: b_ki@hotmail.com
> CC: pgsql-admin@postgresql.org
>
> The design of SSD is such that it cannot run without caching. It has
> to cache to arrange things to be written out due to issues with the
> fact that it cannot write small blocks one at a time but needs to
> write large chunks together at once.
>
> On Thu, May 20, 2010 at 2:10 PM, Balkrishna Sharma <b_ki@hotmail.com> wrote:
> > What if we don't rely on the cache of SSD, i.e. have write-through setting
> > and not write-back. Is the performance gain then not significant to justify
> > SSD ?
> >
> >> Date: Thu, 20 May 2010 13:35:54 -0600
> >> Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server
> >> crash
> >> From: scott.marlowe@gmail.com
> >> To: b_ki@hotmail.com
> >> CC: pgsql-admin@postgresql.org
> >>
> >> SSD and battery backed cache kind of do the same thing, in that they
> >> reduce random access times close to 0. However, most SSDs are still
> >> not considered reliable due to their internal caching systems. hard
> >> drives and bbu RAID are proven solutions, SSD is still not really
> >> there just yet in terms of being proven reliable.
> >>
> >> On Thu, May 20, 2010 at 1:02 PM, Balkrishna Sharma <b_ki@hotmail.com>
> >> wrote:
> >> > Good suggestion. Thanks.
> >> > What's your take on SSD ? I read somewhere that moving the WAL to SSD
> >> > helps
> >> > as well.
> >> >
> >> >> Date: Thu, 20 May 2010 11:36:31 -0600
> >> >> Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server
> >> >> crash
> >> >> From: scott.marlowe@gmail.com
> >> >> To: b_ki@hotmail.com
> >> >> CC: pgsql-admin@postgresql.org
> >> >>
> >> >> On Thu, May 20, 2010 at 10:54 AM, Balkrishna Sharma <b_ki@hotmail.com>
> >> >> wrote:
> >> >> > I need to support several hundreds of concurrent update/inserts from
> >> >> > an
> >> >> > online form with pretty low latency (maybe couple of milliseconds at
> >> >> > max).
> >> >> > Think of a save to database at every 'tab-out' in an online form.
> >> >>
> >> >> You can get nearly the same performance by using a RAID controller
> >> >> with battery backed cache without the same danger of losing
> >> >> transactions.
> >> >>
> >> >> --
> >> >> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> >> >> To make changes to your subscription:
> >> >> http://www.postgresql.org/mailpref/pgsql-admin
> >> >
> >> > ________________________________
> >> > The New Busy is not the too busy. Combine all your e-mail accounts with
> >> > Hotmail. Get busy.
> >>
> >>
> >>
> >> --
> >> When fascism comes to America, it will be intolerance sold as diversity.
> >>
> >> --
> >> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> >> To make changes to your subscription:
> >> http://www.postgresql.org/mailpref/pgsql-admin
> >
> > ________________________________
> > The New Busy is not the old busy. Search, chat and e-mail from your inbox.
> > Get started.
>
>
>
> --
> When fascism comes to America, it will be intolerance sold as diversity.
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2=
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: b_ki@hotmail.com, scott.marlowe@gmail.com
Subject: Re: Asynchronous commit | Transaction loss at server crash
In-Reply-To: <BAY149-w464B3415293316B1A6739AF0E30@phx.gbl>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox