RE: Corrupt Table - Gettting Desparate
От | Hiroshi Inoue |
---|---|
Тема | RE: Corrupt Table - Gettting Desparate |
Дата | |
Msg-id | 000e01c01ebb$a0dc8ca0$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Corrupt Table - Gettting Desparate (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> -----Original Message----- > From: Tom Lane > > "Bryan White" <bryan@arcamax.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 ^^^^ ctid intead of tid ? Hiroshi Inoue
В списке pgsql-general по дате отправления: