One more point, This is observed two times while product firmware updates which updates Postgres 8.4.3 from 8.4.1
Abruptly shutdown never leads to this type of corruption while fsync is always off
Thanks,
Siddharth
Siddharth Shah wrote:
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