On Mon, Jan 11, 2010 at 12:34 PM, Bob Dusek <redusek@gmail.com> wrote:
> Yeah :) We haven't run into much trouble. But, we cut our teeth doing
> performance analysis of our app using PG 7.4. And, people on this list seem
> to be adamantly against this config these days. Is this safer in older
> versions of PG? Or, are the risks the same?
It's always been unsafe. Just that 7.4 was so slow that sometimes you
didn't really get to choose.
> We have some asynchronous communications processes that communicate
> permanent db changes to an enterprise-level data warehouse. And, we can
> recover that data back down to the server if the server goes belly-up. If
> something does go belly up, we really only lose the bit of data that hasn't
> been communicated yet. It's true, that this data is important. However,
> it's also true that it's very costly to guarantee this that very small
> amount of data isn't lost. And, practically speaking (for our purposes) it
> seems that the data's not worth the cost.
I have slave dbs running on four 7200RPM SATA drives with fsync off.
They only get updated from the master db so if they go boom, I just
recreate their node. There's times fsync off is ok, you just have to
know that that db is now considered "disposable".
However, I'd suggest doing some benchmarking to PROVE that you're
seeing an improvement from fsync being off. If there's no
improvement, then you might as well leave it on and save yourself some
headache later on when the machine gets powered off suddenly etc.