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
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 |