RE: Corrupt Table - Gettting Desparate

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general" <pgsql-general(at)postgreSQL(dot)org>, "Bryan White" <bryan(at)arcamax(dot)com>
Subject: RE: Corrupt Table - Gettting Desparate
Date: 2000-09-15 02:21:17
Message-ID: 000e01c01ebb$a0dc8ca0$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> -----Original Message-----
> From: Tom Lane
>
> "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
^^^^
ctid intead of tid ?

Hiroshi Inoue

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2000-09-15 02:25:32 Re: Corrupt Table - Gettting Desparate
Previous Message Tom Lane 2000-09-15 02:04:04 Re: Corrupt Table - Gettting Desparate