Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id D441863263B for ; Fri, 7 May 2010 12:01:42 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 98709-08 for ; Fri, 7 May 2010 15:01:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from elitecore.com (mailhost.elitecore.com [203.88.135.194]) by mail.postgresql.org (Postfix) with ESMTP id A4718632A8D for ; Fri, 7 May 2010 12:01:34 -0300 (ADT) Received: (qmail 29789 invoked from network); 7 May 2010 15:01:32 -0000 Received: from router.elitecore.com (HELO [192.168.1.136]) (siddharth.shah@[203.88.135.193]) (envelope-sender ) by elitecore.com (qmail-ldap-1.03) with SMTP for ; 7 May 2010 15:01:32 -0000 Message-ID: <4BE42B16.8060804@elitecore.com> Date: Fri, 07 May 2010 20:30:38 +0530 From: Siddharth Shah User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Kevin Grittner CC: pgsql-admin@postgresql.org Subject: Re: ERROR: XX001 (Critical and Urgent) References: <4BE3C93C.70800@elitecore.com> <4BE3D0EF020000250003137D@gw.wicourts.gov> <4BE41AE1.4010804@elitecore.com> <4BE3DB1D020000250003138A@gw.wicourts.gov> In-Reply-To: <4BE3DB1D020000250003138A@gw.wicourts.gov> Content-Type: multipart/alternative; boundary="------------060208070909060906040800" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.909 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201005/95 X-Sequence-Number: 34568 This is a multi-part message in MIME format. --------------060208070909060906040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kevin Grittner wrote: > [rearranged to put the most critical point first] > > Siddharth Shah wrote: > > >> I don't have any backup available, Is there any way to fix this ? >> > > I *strongly* recommend that you shut down the database and take a > file copy of the whole data tree (everything under what -D points to > on the server startup) which you should keep until long after you > think everything is working OK again. Before you do anything else. > You are at risk of losing everything in the database, and one > misstep could put you over the edge. If this is a production > database, tell the users that it is down until further notice. > Yes Kevin, I have taken backup of DATADIR. > > >> What can be the method to verify that it's a database corruption ? >> > > >> ERROR: index "pg_class_relname_nsp_index" contains unexpected >> zero page at block 33 >> > > Getting an error like that indicates database corruption. > > >> HINT: Please REINDEX it. >> xdb=# reindex index pg_class_relname_nsp_index; >> >> Now INDEXing taking High CPU and postgres baffled. >> > > That is an index on the table which describes all your tables and > indexes. It normally doesn't take a long time to reindex. You > should consider doing your recovery in single-user mode (*AFTER* you > make that copy): > > http://www.postgresql.org/docs/8.4/interactive/app-postgres.html > > After trying reindex in that context, please post again. > postgres --single -P -D $DATADIR -p 5433 xdb Same behavior in single mode. > > -Kevin > --------------060208070909060906040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kevin Grittner wrote:
[rearranged to put the most critical point first]
 
Siddharth Shah <siddharth.shah@elitecore.com> wrote:
 
  
I don't have any backup available, Is there any way to fix this ?
    
 
I *strongly* recommend that you shut down the database and take a
file copy of the whole data tree (everything under what -D points to
on the server startup) which you should keep until long after you
think everything is working OK again.  Before you do anything else. 
You are at risk of losing everything in the database, and one
misstep could put you over the edge.  If this is a production
database, tell the users that it is down until further notice.
  
    Yes Kevin, I have taken backup of DATADIR.
 
  
What can be the method to verify that it's a database corruption ?
    
 
  
ERROR:  index "pg_class_relname_nsp_index" contains unexpected
zero page at block 33
    
 
Getting an error like that indicates database corruption.
 
  
HINT:  Please REINDEX it.
xdb=# reindex index pg_class_relname_nsp_index;

Now INDEXing taking High CPU and postgres baffled.
    
 
That is an index on the table which describes all your tables and
indexes.  It normally doesn't take a long time to reindex.  You
should consider doing your recovery in single-user mode (*AFTER* you
make that copy):
 
http://www.postgresql.org/docs/8.4/interactive/app-postgres.html
 
After trying reindex in that context, please post again.
  
    postgres --single -P -D $DATADIR -p 5433 xdb
    Same behavior in single mode.
 
-Kevin
  


--------------060208070909060906040800--