Tom Lane wrote:
> Jaime Casanova <jcasanov@systemguards.com.ec> writes:
>> Every time i explain what is the fsync parameter for, the next thing i
>> always say is: "never turn it off", and now that we have
>> synchronous_commit there is no good reason for turn fsync off... so
>> why are we still let it be in the postgresql.conf where it's so
>> vulnerable to a misguided dba?
>
> It's a "never turn it off *in production*" kind of setting. That
> doesn't make it useless --- in development or debug situations it
> might be just fine.
It's also not insane to turn it off if you're log-shipping to another
machine, and you don't mind having to restore from your last PITR log
update.
Some people use MyISAM tables (in MySQL) for raw speed at the cost of
reliability. With Pg and fsync=off you can get much of the speed, but
still have solid transactional behavior and rational handling of bad
data. Sure, you risk downtime if you have to restore, but with a warm
standby following the logs you can just cut over to it while you rebuild
the master.
With the approaching support for upcoming synchronous replication, it
makes even more sense to consider using fsync=off in some environments.
I wouldn't do it personally, but then I don't have apps where losing the
last few minutes' data is in case of failure is acceptable.
--
Craig Ringer