Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 2CA731608A20
	for <pgsql-admin@postgresql.org>; Tue,  7 Aug 2012 22:39:46 -0300 (ADT)
Received: from cl-174.chi-02.us.sixxs.net ([2001:4978:f:ad::2]
	helo=tamriel.snowman.net)
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <sfrost@tamriel.snowman.net>) id 1SyvFQ-0002qV-2t
	for pgsql-admin@postgresql.org; Wed, 08 Aug 2012 01:39:45 +0000
Received: by tamriel.snowman.net (Postfix, from userid 1000)
	id 4E45022B28; Tue,  7 Aug 2012 21:39:31 -0400 (EDT)
Date: Tue, 7 Aug 2012 21:39:31 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Terry Schmitt <tschmitt@schmittworks.com>
Cc: Craig Ringer <ringerc@ringerc.id.au>, pgsql-admin@postgresql.org
Subject: Re: Data corruption after SAN snapshot
Message-ID: <20120808013931.GO1267@tamriel.snowman.net>
References: 
 <CAOOcyswLYBfJDuvNBPMkiNCGNKgK=SiexUuTVHCh2O+Y1T-sLw@mail.gmail.com>
	<5021BCA6.7030000@ringerc.id.au>
	<CAOOcysxktC6qkc0j4cruhtA5Ec5BLDb9Q0hX9YWkb8G7F1_JdA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0arQRo42ogU2PCTe"
Content-Disposition: inline
In-Reply-To: 
 <CAOOcysxktC6qkc0j4cruhtA5Ec5BLDb9Q0hX9YWkb8G7F1_JdA@mail.gmail.com>
X-Editor: Vim http://www.vim.org/
X-Info: http://www.snowman.net
X-Operating-System: Linux/3.2.0-1-amd64 (x86_64)
X-Uptime: 21:37:24 up 163 days,  7:42,  7 users,  load average: 0.00, 0.03,
	0.05
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201208/47
X-Sequence-Number: 39868


--0arQRo42ogU2PCTe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Terry,

* Terry Schmitt (tschmitt@schmittworks.com) wrote:
> So far, executing pg_dumpall
> seems to be fairly reliable for finding the corrupt objects after my
> initial data load, but unfortunately much of the corruption has been with
> indexes which pgdump will not expose.

Shouldn't be too hard to write a script that'll do a query against each
table using an ORDER BY that matches each index, at least for 'simple'
indexes, which'll typically cause an in-order index traversal.

Just a thought.

	Thanks,

		Stephen

--0arQRo42ogU2PCTe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlAhw1MACgkQrzgMPqB3kiiq1ACgmg2dmippuYwqm2camQxBv6ze
kPEAoIahmuWFBX24Mnds6V6n4TFGiVvH
=0aWd
-----END PGP SIGNATURE-----

--0arQRo42ogU2PCTe--