Message-ID: <4C80B50E.8050900@wp.pl>
Date: Fri, 03 Sep 2010 10:42:54 +0200
From: Ireneusz Pluta <ipluta@wp.pl>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: Autovacuum and invalid page header
References: <4BEA8CD0.8070108@wp.pl>
 <4BEBC57002000025000316A3@gw.wicourts.gov>
In-Reply-To: <4BEBC57002000025000316A3@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kevin Grittner pisze:
> Ireneusz Pluta <ipluta@wp.pl> wrote:
>
>   
>> Is there
>> any ready tool, which, for instance when given a path to database
>> cluster, would traverse all cluster directories and files and
>> check all page headers? I probably answered myself - manual VACUUM
>> [VERBOSE] would do - but it fails when finds the first invalid
>> header, so I would have. That's why I am looking for something
>> only scanning and reporting invalid headers.
>>     
>  
> I don't know of anything, but you might try searching pgfoundry.
>   
Continuing revisiting my old thread, and to answer myself:
find and pg_filedump seem to be the way, more-less like:
find $PGDATA -type f -name [0-9]* |   while read f; do echo $f && 
pg_filedump $f | grep -i invalid; done
# not tested yet
- of course keeping in mind that newly allocated pages might appear 
invalid to pg_filedump, while the server is running, as Tom explained 
just recently:
> A newly-added page on disk will
> be initially filled with zeroes, which I think pg_filedump will complain
> about.  It won't get overwritten with "valid" data until the page is
> next written, either because of a checkpoint or because the buffer space
> is needed for another page.  pg_filedump can't see the state of the page
> within the server's buffers, which is what counts here.