On Mon, Nov 16, 2009 at 2:04 PM, Robert Schnabel <schnabelr@xxxxxxxxxxxx> wrote: > Granted, but the point of me testing this is to say whether or not the > Diskeeper service could introduce a problem. If the system recovers without > Diskeeper running but does not recover while Diskeeper is actively running > then we have a problem. If they both recover then I've answered the > question "Have you unplugged the power cord a few times in the middle of > heavy write activity?" I understand that we can't prove that it works but I > should be able to at least answer the question asked. > > I wouldn't consider my database a production one. I basically use it to > store a large amount of genetic data for my lab. The only time the database > gets use is when I use it. Short of frying a piece of hardware by pulling > the plug I'm not worried about losing any data and rebuilding is actually > quite a simple process that only takes about 2 hours... been there done that > when I pulled the wrong SAS connector. Be careful, it's not uncommon for a database / app to suddenly become popular and people start expecting it to be up all the time. For things like a corporate intranet, losing a few hours work from something like a power loss is acceptable. We have four types of dbs where I work. session servers can be configured to have fsync off and don't have to be ultra reliable under things like power loss. Search database which gets recreated every few days as the indexer runs. Stats database where reliability is sorta important but not life or death, and the user data database which has to work and stay up. So each one is tested differently because each one would have a much different impact if they crash and can't come back up without help. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
