Tim Ellis <Tim.Ellis@gamet.com> writes:
> (in summation...) So if data consistency is the most important thing to
> me, performance be damned, I still, as of 7.2.1, want to run in fsync
> mode?
Yup. no-fsync is only suitable if you trust your OS and power supply.
You do not have to trust Postgres itself: in all cases we push the log
entries out to the OS before declaring a transaction committed. The
question at hand is whether we use fsync() or other methods to try to
force the OS to write to disk before we report the transaction
committed. Without that, a system-level crash immediately after a
commit report might mean the "committed" transaction isn't reflected as
committed on disk.
The performance cost of fsync is not nearly what it used to be pre-7.1,
btw, because we need flush only the WAL log file not data files.
(In case of a crash, any missing data-file updates will be reconstructed
from the recent WAL entries during restart.) So the needed disk head
movement is a lot less than it used to be --- especially if you've
arranged for pg_xlog to live on its own disk. I don't think there's any
longer a good argument for considering no-fsync in production servers,
even though you might well still choose it for development systems.
regards, tom lane
