Re: Why Wal_buffer is 64KB

From: Tadipathri Raghu <traghu(dot)dba(at)gmail(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Pierre C <lists(at)peufeu(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Why Wal_buffer is 64KB
Date: 2010-03-29 06:00:43
Message-ID: 645d9d71003282300j6ef4a9d5pbfa257667e6a7e3a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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 <scott(dot)marlowe(at)gmail(dot)com>wrote:

> On Fri, Mar 26, 2010 at 7:43 AM, Pierre C <lists(at)peufeu(dot)com> 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.
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2010-03-29 06:45:44 Re: Why Wal_buffer is 64KB
Previous Message Tadipathri Raghu 2010-03-29 04:56:33 Re: Optimizer showing wrong rows in plan