Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: how unsafe (or worst scenarios) when setting fsync
- From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- To: Simon Riggs <simon(at)2ndquadrant(dot)com>
- Cc: guoping(dot)zhang(at)nec(dot)com(dot)au, pgsql-performance(at)postgresql(dot)org, "Guoping Zhang (E-mail)" <guopingz(at)nstc(dot)nec(dot)com(dot)au>
- Subject: Re: how unsafe (or worst scenarios) when setting fsync
- Date: Thu, 27 Apr 2006 10:57:46 -0400
Simon Riggs <simon(at)2ndquadrant(dot)com> writes: > On Thu, 2006-04-27 at 16:31 +1000, Guoping Zhang wrote: >> Can we set fsync OFF for the performance benefit, have the risk of only 5 >> minutes data loss or much worse? > Thats up to you. > fsync can be turned on and off, so you can make critical changes with > fsync on, then continue with fsync off. I think it would be a mistake to assume that the behavior would be nice clean "we only lost recent changes". Things could get arbitrarily badly corrupted if some writes make it to disk and some don't. regards, tom lane
- Follow-Ups:
- Re: how unsafe (or worst scenarios) when setting fsync
- From: Guoping Zhang
- Re: how unsafe (or worst scenarios) when setting fsync
- References:
- how unsafe (or worst scenarios) when setting fsync OFF for postgresql
- From: Guoping Zhang
- Re: how unsafe (or worst scenarios) when setting fsync
- From: Simon Riggs
- how unsafe (or worst scenarios) when setting fsync OFF for postgresql
- Prev by Date: Re: how unsafe (or worst scenarios) when setting fsync OFF for postgresql
- Next by Date: Re: Large (8M) cache vs. dual-core CPUs
- Previous by thread: Re: how unsafe (or worst scenarios) when setting fsync
- Next by thread: Re: how unsafe (or worst scenarios) when setting fsync
- Indexes: