On Mittwoch, 30. April 2008 Tom Lane wrote: > I finally got a chance to do some analysis, and what I find is > multiple instances of index corruption. There are 18 index pages > that are all zeroes: > [snip] > On the whole I'm thinking that you may have an intermittent hardware > problem, especially since we've not seen comparable symptoms reported > by anyone else. We've had a bad crash once where the server couldn't write it's buffers. The RAID controller also caches writes, and the server is in VMware, which I guess adds to the problem as the whole client machine also has caches and so on. I now remember we had a (very NOT important) database that we simply deleted and recreated as it's only for a web-app without data in it, but didn't see any other problems at that time. So probably this is this kind of "should never ever happen" except your machine goes bye-bye badly. What makes me a bit worried is that pg_dump did not report an error at all, but made it's backup as if everything is OK. Could that be changed maybe so that in case of a problem it at least cries out loudly "broken db found" or so? Or even better it should not create a backup file but say "to save this broken db please recall pg_dump with --ignore-broken-db". We would have found it earlier if the backup wouldn't have worked. It's always good to have that kind of extra warnings, better than oversee problems. Thanks for your analyzation. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0676/846 914 666 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: www.keyserver.net Key-ID: 1C1209B4
Attachment:
signature.asc
Description: This is a digitally signed message part.
