On Mon, Mar 29, 2010 at 2:00 AM, Tadipathri Raghu wrote:
> 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
> filen
Hi Scott,
Yes, May i know any particular reason for behaving this. Are its looking for
any consistency. I havnt got any clear picture here.
Could you Please explain this..
Thanks & Regards
Raghavendra
On Mon, Mar 29, 2010 at 12:15 PM, Scott Marlowe wrote:
> On Mon, Mar 29, 2010 at 12:00 AM, Tad
On Mon, Mar 29, 2010 at 12:00 AM, Tadipathri Raghu wrote:
> 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 w
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
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.
Th
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.
More info is needed about your configuration (hardware, d
Hi Pierre,
First of all , I Thank all for sharing the information on this Issue.
On Thu, Mar 25, 2010 at 11:44 PM, Pierre C wrote:
>
> If you do large transactions, which emits large quantities of xlog, be
> aware that while the previous xlog segment is being fsynced, no new writes
> happen to
If you do large transactions, which emits large quantities of xlog, be
aware that while the previous xlog segment is being fsynced, no new writes
happen to the next segment. If you use large wal_buffers (more than 16 MB)
these buffers can absorb xlog data while the previous segment is being
On Thu, Mar 25, 2010 at 11:01 AM, Tadipathri Raghu wrote:
> Hi All,
>
> Can anybody clarify on this, why wal_buffer is 64kb and what is advantages
> and disadvantages in increasing or decreasing the wal_buffer.
>
is 64kb just because by default we have low values in almost everything :)
and the a
On Thu, 2010-03-25 at 20:31 +0530, Tadipathri Raghu wrote:
> Hi All,
>
> Can anybody clarify on this, why wal_buffer is 64kb and what is
> advantages and disadvantages in increasing or decreasing the
> wal_buffer.
This is addressed in the documentation.
http://www.postgresql.org/docs/8.4/intera
Hi All,
Can anybody clarify on this, why wal_buffer is 64kb and what is advantages
and disadvantages in increasing or decreasing the wal_buffer.
Regards
Raghav
11 matches
Mail list logo
