On Mon, May 2, 2016 at 12:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2016-05-02 10:07:50 -0400, Robert Haas wrote: >>> - If that flag is set on a subsequent startup, say: >>> WARNING: Recovery was previously performed with fsync=off; this >>> cluster may be irretrievably corrupted. > >> Well, the problem with that is that postgres crashes are actually >> harmless with regard to fsync=on/off. It's just OS crashes that are a >> problem. So it seems quite likely that the false-positive rate here >> would be high enough, to make people ignore it. > > That's a pretty good point. Also, as sketched, I believe this would > start bleating after a crash recovery performed because a backend > died --- which is a case where we know for certain there was no OS > crash. So this idea needs some more thought.
That's true. I think, that we could arrange to ignore postmaster initiated crash-and-restart cycles in deciding whether to set the flag. Now, somebody could still do an immediate shutdown, or the postmaster could go boom, but I don't think those are common enough scenarios to justify not tracking this. If you are using fsync=off and running an immediate shutdown and then setting fsync=on and restarting the server ... yeah, that could hypothetically be safe. But I think you are playing with fire. If you are using fsync=off for the initial data load, it's not too much to ask that you shut the cluster down cleanly when you are done. -- 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
