Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id BCCA22E0042 for ; Wed, 7 May 2008 11:42:47 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 59813-02 for ; Wed, 7 May 2008 11:42:37 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by developer.postgresql.org (Postfix) with ESMTP id EC15D2E0052 for ; Wed, 7 May 2008 11:42:42 -0300 (ADT) Received: from mailsrv.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailsrv.i.zmi.at", Issuer "mailsrv.i.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 782A5C2E for ; Wed, 7 May 2008 16:43:12 +0200 (CEST) Received: from saturn.i.zmi.at (saturn.i.zmi.at [10.0.0.2]) by mailsrv.i.zmi.at (Postfix) with ESMTP id 7A1D2BFE9 for ; Wed, 7 May 2008 16:41:36 +0200 (CEST) From: Michael Monnerie 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 16:42:38 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <200804141757.21574@zmi.at> <200805071103.53981@zmi.at> <6626.1210170774@sss.pgh.pa.us> In-Reply-To: <6626.1210170774@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1775031.nky2X1aYXx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200805071642.39041@zmi.at> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.012 tagged_above=0 required=5 tests=AWL=0.012 X-Spam-Level: X-Archive-Number: 200805/49 X-Sequence-Number: 29133 --nextPart1775031.nky2X1aYXx Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mittwoch, 7. Mai 2008 Tom Lane wrote: > pg_dump intentionally does *not* look at the contents of indexes (at > least not any on user tables). =A0I think this is a good thing because > it makes it more likely that you can dump a damaged database. > =A0pg_dump is not supposed to be some kind of fsck-like tool. OK, I see that normally you should get that info out of the postgresql=20 log. The problem with this application is, that often it happens to try=20 an insert on already existing primary keys, which makes you overlook=20 the problem is real. Maybe something can be improved here, but I don't=20 know what would be the best way. Maybe a big log line like YOUR DATABASE xxx SEEMS TO BE DAMAGED - PLEASE CHECK such a line would jump into the eyes even on a big log, and it makes you=20 nervous enough to really check things. 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 --nextPart1775031.nky2X1aYXx 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) iD8DBQBIIb/fzhSR9xwSCbQRAk+RAKDvuHCVCbXkm8mDpcLns1CZbHI5zACg7kgj 5fgo+mFF7gWncR3VUat8NNg= =LUY/ -----END PGP SIGNATURE----- --nextPart1775031.nky2X1aYXx--