On Fri, May 8, 2015 at 7:53 PM, Andres Freund <and...@anarazel.de> wrote: > On 2015-05-04 14:23:16 -0400, Robert Haas wrote: >> On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen <a...@2ndquadrant.com> >> wrote: >> > As for the non-backpatchable 0002, I agree with Andres that it should be >> > included in 9.5; but I take it you're still not convinced? >> >> No, I'm not convinced. That patch will protect you in one extremely >> specific scenario: you turn off fsync, do some stuff, shut down, turn >> fsync back on again, and start up. > > Hm. ISTM it'd not be hard to actually make it safe in nearly all > situations. What about tracking the last checkpoint's fsync setting and > do a fsync_pgdata() in the checkpointer at the end of a checkpointer if > the previous setting was off and the current one is on? Combined with > doing so at startup if the settings changed between runs, that should > give pretty decent protection. And seems fairly simple to implement.
That seems a bit better. I think it's really important, if we're going to start to try to make fsync=off anything other than a toy, that we document really clearly the circumstances in which it is or is not safe: - If you crash while fsync=off, your cluster may be corrupted. - If you crash while fsync=on, but it was off at the last checkpoint, your cluster may be corrupted. - If you turn fsync=off, do stuff, turn fsync=on, and checkpoint successfully, a subsequent crash should not corrupt anything. Of course, even the last one isn't totally bullet-proof. Suppose one backend fails to absorb the new setting for some reason... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
