Scott Marlowe 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.On Mon, Nov 16, 2009 at 1:32 PM, Robert Schnabel <schnabelr@xxxxxxxxxxxx> wrote:Ok, so you have sufficiently sparked my curiosity as to whether Diskeeper will in any way cause Postgres to fail the power chord test. Unfortunately I have some deadlines to meet so won't be able to test this out until laterBest time is during acceptance testing before deployment. Failing that testing it in production on the backup server so you can burn it to the ground and rebuild it on a saturday. Note that surviving the power plug being pulled doesn't PROVE your system will always do that. You can try to simulate the real mix of load and even replay queries when pulling the plug, only to find the one corner case you didnt' test in production when power is lost. The power cord plug can prove a system bad, but you're still somewhat "hoping" it's really good, with a high probability of being right. Which is why backup is so important. 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. Bob |