Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id C671E633397 for ; Mon, 29 Mar 2010 03:01:42 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 10598-01 for ; Mon, 29 Mar 2010 06:01:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-vw0-f46.google.com (mail-vw0-f46.google.com [209.85.212.46]) by mail.postgresql.org (Postfix) with ESMTP id 0AD6563271B for ; Mon, 29 Mar 2010 03:00:43 -0300 (ADT) Received: by vws8 with SMTP id 8so2348295vws.19 for ; Sun, 28 Mar 2010 23:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=M/McKT2llerAWTns3mxPIHrtTyZdh7AY+n9CWWQncKU=; b=iIzB1YRI8Ke10mJTqgUcsG+6LQOsKh6b/pK4nVa8cC7angG75zi36od9nF646izbFV znDju9bVu0WyOhUyPkXQpu9iu+RcUIanh9iyH0BWoyeoGcrJ5lE8NYq1qiHDbc3VN0gi VVM+rCHfRwgJP8H2qlGWB5RgCIK4LLsGR9Ses= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=m2glNKdFQ+n2saXfUtIDoI4detoHr+G7OYnesSyuxSEJkC5O2I8vuN2kmpsNxJQdix RgD+7E8c6+U6gPcRjCF5tA6vXbbvDfYn7nqQholyNUqNEfFNacCd99S27D/lkpxXpdiu T12ruJKo7rBE27+xjOKhOJu3sPxwMu/AZ5Zvg= MIME-Version: 1.0 Received: by 10.220.99.197 with HTTP; Sun, 28 Mar 2010 23:00:43 -0700 (PDT) In-Reply-To: References: <645d9d71003250801o246439a0j93c7b568786e98de@mail.gmail.com> <3073cc9b1003251015x590e962ata59dadbb58b42ce5@mail.gmail.com> <645d9d71003252019u6f01a513x7876c1a97b448dea@mail.gmail.com> Date: Mon, 29 Mar 2010 11:30:43 +0530 Received: by 10.220.124.129 with SMTP id u1mr2703834vcr.25.1269842443268; Sun, 28 Mar 2010 23:00:43 -0700 (PDT) Message-ID: <645d9d71003282300j6ef4a9d5pbfa257667e6a7e3a@mail.gmail.com> Subject: Re: Why Wal_buffer is 64KB From: Tadipathri Raghu To: Scott Marlowe Cc: Pierre C , Jaime Casanova , pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=00163691fbc5c074250482ea3b3d X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.974 tagged_above=-10 required=5 tests=AWL=0.624, BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201003/364 X-Sequence-Number: 38189 --00163691fbc5c074250482ea3b3d Content-Type: text/plain; charset=ISO-8859-1 Hi All, Thank you for all the support. I have noticed one more thing here, that if you turn off the fsync and try to run the transaction than its breaking the currnet filenode and generating another filenode. Is it true that whenever you turn off or on the fsync the filenode will break and create one more on that table. Regards Raghavendra On Fri, Mar 26, 2010 at 7:30 PM, Scott Marlowe wrote: > On Fri, Mar 26, 2010 at 7:43 AM, Pierre C wrote: > > > >> After fsync/syncronous_commit off > > > > Do not use fsync off, it is not safe. Who cares about the performance of > > fsync=off, when in practice you'd never use it with real data. > > synchronnous_commit=off is fine for some applications, though. > > There are situations where it's ok, when all the data are > reproduceable from other sources, etc. for instance I have a > reporting server that is a slony slave that runs with fsync off. If > it does crash and I can recreate the node in an hour or so and be back > online. With fsync off the machine is too slow to do its job, and > it's not the primary repo of the real data, so it's ok there. > --00163691fbc5c074250482ea3b3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0
Thank you for all the support.
=A0
I have noticed one more thing here, that if you turn off the fsync and= try to run the transaction than its breaking the currnet filenode and gene= rating another filenode. Is it true that whenever you turn off or on the fs= ync the filenode will break and create one more on that table.
=A0
Regards
Raghavendra

On Fri, Mar 26, 2010 at 7:30 PM, Scott Marlowe <= span dir=3D"ltr"><scott.marlo= we@gmail.com> wrote:
On Fri, Mar 26, 2010 at 7:43 AM, Pierre C <lists@peufeu.com> wrote:
>
>>= ; After fsync/syncronous_commit off
>
> Do not use fsync off, i= t is not safe. Who cares about the performance of
> fsync=3Doff, when in practice you'd never use it with real data.> synchronnous_commit=3Doff is fine for some applications, though.
=
There are situations where it's ok, when all the data are
reproduceable from other sources, etc. =A0for instance I have a
reportin= g server that is a slony slave that runs with fsync off. =A0If
it does c= rash and I can recreate the node in an hour or so and be back
online. = =A0With fsync off the machine is too slow to do its job, and
it's not the primary repo of the real data, so it's ok there.

--00163691fbc5c074250482ea3b3d--