Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id EEA08632D9C for ; Thu, 20 May 2010 17:26:52 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 24779-05 for ; Thu, 20 May 2010 20:26:44 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from bay0-omc3-s25.bay0.hotmail.com (bay0-omc3-s25.bay0.hotmail.com [65.54.190.163]) by mail.postgresql.org (Postfix) with ESMTP id A12CA63222E for ; Thu, 20 May 2010 17:26:44 -0300 (ADT) Received: from BAY149-W46 ([65.54.190.189]) by bay0-omc3-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 May 2010 13:26:43 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ae8c14c1-f39e-4047-a7a5-e4e7a599d46b_" X-Originating-IP: [129.44.63.215] From: Balkrishna Sharma To: CC: Subject: Re: Asynchronous commit | Transaction loss at server crash Date: Thu, 20 May 2010 16:26:42 -0400 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 20 May 2010 20:26:43.0051 (UTC) FILETIME=[C2AF8BB0:01CAF85A] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.909 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201005/202 X-Sequence-Number: 34675 --_ae8c14c1-f39e-4047-a7a5-e4e7a599d46b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But if we have write-through setting=2C 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 noti= fication 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=2C 20 May 2010 14:12:33 -0600 > Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at server cra= sh > From: scott.marlowe@gmail.com > To: b_ki@hotmail.com > CC: pgsql-admin@postgresql.org >=20 > 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. >=20 > On Thu=2C May 20=2C 2010 at 2:10 PM=2C Balkrishna Sharma wrote: > > What if we don't rely on the cache of SSD=2C i.e. have write-through se= tting > > and not write-back. Is the performance gain then not significant to jus= tify > > SSD ? > > > >> Date: Thu=2C 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=2C in that they > >> reduce random access times close to 0. However=2C most SSDs are still > >> not considered reliable due to their internal caching systems. hard > >> drives and bbu RAID are proven solutions=2C SSD is still not really > >> there just yet in terms of being proven reliable. > >> > >> On Thu=2C May 20=2C 2010 at 1:02 PM=2C Balkrishna Sharma > >> wrote: > >> > Good suggestion. Thanks. > >> > What's your take on SSD ? I read somewhere that moving the WAL to SS= D > >> > helps > >> > as well. > >> > > >> >> Date: Thu=2C 20 May 2010 11:36:31 -0600 > >> >> Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at serv= er > >> >> crash > >> >> From: scott.marlowe@gmail.com > >> >> To: b_ki@hotmail.com > >> >> CC: pgsql-admin@postgresql.org > >> >> > >> >> On Thu=2C May 20=2C 2010 at 10:54 AM=2C Balkrishna Sharma > >> >> wrote: > >> >> > I need to support several hundreds of concurrent update/inserts f= rom > >> >> > 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 w= ith > >> > Hotmail. Get busy. > >> > >> > >> > >> -- > >> When fascism comes to America=2C it will be intolerance sold as divers= ity. > >> > >> -- > >> 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=2C chat and e-mail from your i= nbox. > > Get started. >=20 >=20 >=20 > --=20 > When fascism comes to America=2C it will be intolerance sold as diversity= . >=20 > --=20 > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin =20 _________________________________________________________________ Hotmail is redefining busy with tools for the New Busy. Get more from your = inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=3DPID28326::T:WLMTAGL:O= N:WL:en-US:WM_HMP:042010_2= --_ae8c14c1-f39e-4047-a7a5-e4e7a599d46b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
But if we have write-through setting=2C failure before the cache can w= rite to disk will result in incomplete transaction (i.e. host will know tha= t the transaction was incomplete). Right ?

Two thi= ngs I need for my system is:
1. Unsuccessful transactions with a = notification back that it is unsuccessful is ok but telling it is a =3B= successful =3Btransaction and not being able to write to database is no= t acceptable (ever).
2. My write time (random access time) should= be as minimal as possible.

Can a SSD with write-t= hru cache achieve this ?

Thanks for your inputs.


>=3B Date: Thu=2C 20 May 2010 14:12:33 -0600<= br>>=3B Subject: Re: [ADMIN] Asynchronous commit | Transaction loss at se= rver crash
>=3B From: scott.marlowe@gmail.com
>=3B To: b_ki@hotma= il.com
>=3B CC: pgsql-admin@postgresql.org
>=3B
>=3B The de= sign of SSD is such that it cannot run without caching. It has
>=3B t= o cache to arrange things to be written out due to issues with the
>= =3B fact that it cannot write small blocks one at a time but needs to
&g= t=3B write large chunks together at once.
>=3B
>=3B On Thu=2C Ma= y 20=2C 2010 at 2:10 PM=2C Balkrishna Sharma <=3Bb_ki@hotmail.com>=3B w= rote:
>=3B >=3B What if we don't rely on the cache of SSD=2C i.e. ha= ve write-through setting
>=3B >=3B and not write-back. Is the perfor= mance gain then not significant to justify
>=3B >=3B SSD ?
>=3B= >=3B
>=3B >=3B>=3B Date: Thu=2C 20 May 2010 13:35:54 -0600
&= gt=3B >=3B>=3B Subject: Re: [ADMIN] Asynchronous commit | Transaction l= oss at server
>=3B >=3B>=3B crash
>=3B >=3B>=3B From: sco= tt.marlowe@gmail.com
>=3B >=3B>=3B To: b_ki@hotmail.com
>=3B = >=3B>=3B CC: pgsql-admin@postgresql.org
>=3B >=3B>=3B
>= =3B >=3B>=3B SSD and battery backed cache kind of do the same thing=2C = in that they
>=3B >=3B>=3B reduce random access times close to 0. = However=2C most SSDs are still
>=3B >=3B>=3B not considered reliab= le due to their internal caching systems. hard
>=3B >=3B>=3B drive= s and bbu RAID are proven solutions=2C SSD is still not really
>=3B &g= t=3B>=3B there just yet in terms of being proven reliable.
>=3B >= =3B>=3B
>=3B >=3B>=3B On Thu=2C May 20=2C 2010 at 1:02 PM=2C Bal= krishna Sharma <=3Bb_ki@hotmail.com>=3B
>=3B >=3B>=3B wrote:>=3B >=3B>=3B >=3B Good suggestion. Thanks.
>=3B >=3B>= =3B >=3B What's your take on SSD ? I read somewhere that moving the WAL t= o SSD
>=3B >=3B>=3B >=3B helps
>=3B >=3B>=3B >=3B as = well.
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >=3B>=3B Dat= e: Thu=2C 20 May 2010 11:36:31 -0600
>=3B >=3B>=3B >=3B>=3B Su= bject: Re: [ADMIN] Asynchronous commit | Transaction loss at server
>= =3B >=3B>=3B >=3B>=3B crash
>=3B >=3B>=3B >=3B>=3B Fro= m: scott.marlowe@gmail.com
>=3B >=3B>=3B >=3B>=3B To: b_ki@hot= mail.com
>=3B >=3B>=3B >=3B>=3B CC: pgsql-admin@postgresql.org=
>=3B >=3B>=3B >=3B>=3B
>=3B >=3B>=3B >=3B>=3B On= Thu=2C May 20=2C 2010 at 10:54 AM=2C Balkrishna Sharma <=3Bb_ki@hotmail.= com>=3B
>=3B >=3B>=3B >=3B>=3B wrote:
>=3B >=3B>=3B= >=3B>=3B >=3B I need to support several hundreds of concurrent updat= e/inserts from
>=3B >=3B>=3B >=3B>=3B >=3B an
>=3B >= =3B>=3B >=3B>=3B >=3B online form with pretty low latency (maybe co= uple of milliseconds at
>=3B >=3B>=3B >=3B>=3B >=3B max).>=3B >=3B>=3B >=3B>=3B >=3B Think of a save to database at eve= ry 'tab-out' in an online form.
>=3B >=3B>=3B >=3B>=3B
>= =3B >=3B>=3B >=3B>=3B You can get nearly the same performance by us= ing a RAID controller
>=3B >=3B>=3B >=3B>=3B with battery back= ed cache without the same danger of losing
>=3B >=3B>=3B >=3B>= =3B transactions.
>=3B >=3B>=3B >=3B>=3B
>=3B >=3B>= =3B >=3B>=3B --
>=3B >=3B>=3B >=3B>=3B Sent via pgsql-admi= n mailing list (pgsql-admin@postgresql.org)
>=3B >=3B>=3B >=3B&g= t=3B To make changes to your subscription:
>=3B >=3B>=3B >=3B>= =3B http://www.postgresql.org/mailpref/pgsql-admin
>=3B >=3B>=3B &= gt=3B
>=3B >=3B>=3B >=3B ________________________________
>= =3B >=3B>=3B >=3B The New Busy is not the too busy. Combine all your = e-mail accounts with
>=3B >=3B>=3B >=3B Hotmail. Get busy.
&g= t=3B >=3B>=3B
>=3B >=3B>=3B
>=3B >=3B>=3B
>=3B &= gt=3B>=3B --
>=3B >=3B>=3B When fascism comes to America=2C it w= ill be intolerance sold as diversity.
>=3B >=3B>=3B
>=3B >= =3B>=3B --
>=3B >=3B>=3B Sent via pgsql-admin mailing list (pgsq= l-admin@postgresql.org)
>=3B >=3B>=3B To make changes to your subs= cription:
>=3B >=3B>=3B http://www.postgresql.org/mailpref/pgsql-a= dmin
>=3B >=3B
>=3B >=3B ________________________________
= >=3B >=3B The New Busy is not the old busy. Search=2C chat and e-mail f= rom your inbox.
>=3B >=3B Get started.
>=3B
>=3B
>= =3B
>=3B --
>=3B When fascism comes to America=2C it will be in= tolerance sold as diversity.
>=3B
>=3B --
>=3B Sent via pg= sql-admin mailing list (pgsql-admin@postgresql.org)
>=3B To make chang= es to your subscription:
>=3B http://www.postgresql.org/mailpref/pgsql= -admin

Hotmail is redefining busy with too= ls for the New Busy. Get more from your inbox. See how. = --_ae8c14c1-f39e-4047-a7a5-e4e7a599d46b_--