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