From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Steve Wampler <swampler(at)noao(dot)edu> |
Cc: | postgres-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Repairing bad table? |
Date: | 2001-04-13 16:17:54 |
Message-ID: | 4291.987178674@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Steve Wampler <swampler(at)noao(dot)edu> writes:
> I need help - I've had a system crash that has left a table with some
> invalid OIDs. How do I clean this up? If I try a vacuum analyze,
> I get:
> configdb=# vacuum analyze;
> NOTICE: Rel attributes_table: TID 3304/23: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel attributes_table: TID 3304/28: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel attributes_table: TID 3304/31: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel attributes_table: TID 3304/33: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel attributes_table: TID 3304/40: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel attributes_table: TID 3304/41: OID IS INVALID. TUPGONE 1.
> NOTICE: Rel attributes_table: TID 3304/77: OID IS INVALID. TUPGONE 1.
> FATAL 1: Memory exhausted in AllocSetAlloc()
Try not doing "analyze" --- the most likely cause of the FATAL message is
that the system is trying to copy some damaged column value that
claims to be ridiculously wide.
If nothing else helps, you could manually zero block 3304 of the table,
sacrificing those rows to get back the rest of your data. dd(1) should
work for this, I think, but be sure to shut down the postmaster while
hacking directly on data files. [NB: these are 8K blocks (unless you
changed BLCKSZ) and the file starts with block zero.]
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-04-13 16:22:22 | Re: Question about SELECT FOR UPDATE in transaction, isolation level |
Previous Message | David M. Kaplan | 2001-04-13 15:28:19 | join queries |