On 07/16/2012 09:37 AM, Tom Lane wrote:
Sounds reasonable to me; I tend to view fsync=off as a testing feature anyway. Will clone onto -general and see if anyone yells.There's one way that doesn't have any housekeeping cost to Pg. It's pretty bad manners if there's anybody other than Pg on the system though: sync()Yeah, I thought about that: if we could document that issuing a manual sync after turning fsync on leaves you in a guaranteed-good state once the sync is complete, it'd probably be fine. However, I'm not convinced that we could promise that with a straight face. In the first place, PG has only very weak guarantees about how quickly all processes in the system will absorb a GUC update. In the second place, I'm not entirely sure that there aren't race conditions around checkpoints and the fsync request queue (particularly if we do what Jeff is suggesting and suppress queuing requests at the upstream end). It might be all right, or it might be all right after expending some work, but the whole thing is not an area where I think anyone wants to spend time. I think it'd be much safer to document that the correct procedure is "stop the database, do a manual sync, enable fsync in postgresql.conf, restart the database". And if that's what we're documenting, we lose little or nothing by marking fsync as PGC_POSTMASTER.
-- Craig Ringer -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
