From: Michael Monnerie <michael.monnerie@it-management.at>
Organization: it-management http://it-management.at
To: pgsql-admin@postgresql.org
Subject: Re: duplicate primary index in bayes db from SpamAssassin
Date: Wed, 7 May 2008 11:03:53 +0200
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <200804141757.21574@zmi.at> <20473.1208446891@sss.pgh.pa.us>
	<21948.1209587149@sss.pgh.pa.us>
In-Reply-To: <21948.1209587149@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6390375.irbMVBLTzU";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200805071103.53981@zmi.at>

--nextPart6390375.irbMVBLTzU
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.=20
The RAID controller also caches writes, and the server is in VMware,=20
which I guess adds to the problem as the whole client machine also has=20
caches and so on. I now remember we had a (very NOT important) database=20
that we simply deleted and recreated as it's only for a web-app without=20
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=20
machine goes bye-bye badly. What makes me a bit worried is that pg_dump=20
did not report an error at all, but made it's backup as if everything=20
is OK. Could that be changed maybe so that in case of a problem it at=20
least cries out loudly "broken db found" or so? Or even better it=20
should not create a backup file but say "to save this broken db please=20
recall pg_dump with --ignore-broken-db". We would have found it earlier=20
if the backup wouldn't have worked.
It's always good to have that kind of extra warnings, better than=20
oversee problems.

Thanks for your analyzation.

mfg zmi
=2D-=20
// 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

--nextPart6390375.irbMVBLTzU
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBIIXB5zhSR9xwSCbQRAsmZAJ4mmPM7riRnJslQ3dQIuqWcybdBrwCgrPVA
x2M+pYAs0TILnm+bC/tjvJk=
=31TP
-----END PGP SIGNATURE-----

--nextPart6390375.irbMVBLTzU--