Re: Corrupt Table - Gettting Desparate

"Bryan White" <bryan(at)arcamax(dot)com> writes:
> Ok I nulled out the bad pages. A pg_dump still fails. I just noticed there
> are 21000 files in my database directory. Most of the form INDEXNAME.NUMBER
> where INDEXNAME is the name of one of my indexes and NUMBER is a sequential
> number. There are 4 or 5 different indexes involved. All of these files
> are 0 bytes in size. All dated in the last day or two.

This suggests corrupted pointers inside the indexes. I wouldn't worry
too much about it, you have bigger problems :-(. The indexes are not
what's keeping you from dumping the database, anyway.

> When I did the pg_dump I got this in the log file:
> 000914.18:00:07.600 [10406] FATAL 1: Memory exhausted in AllocSetAlloc()
> Smart Shutdown request at Thu Sep 14 18:07:15 2000

> The dump died after putting 100MB in the output file.

> My guess is the internal structure of one of the tuples is corrupt.

So it would seem. Evidently there's at least one more corrupted page
besides the ones you were able to identify before.

What I did the last time I had to identify a corrupted tuple was to try
SELECT tid,* FROM table LIMIT 1 OFFSET n
and experiment with different values of n to home in on the corrupted
tuple. The last tuple you can print this way without a crash is the
one before the damaged tuple. The TID of that tuple gives you the
block number it's in.

regards, tom lane