| From: | Bob Ippolito <bob(at)redivi(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL 8.1.0 catalog corruption |
| Date: | 2005-11-21 22:24:21 |
| Message-ID: | 5FE54230-0544-4082-9D05-264C2C3BEBA3@redivi.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Nov 21, 2005, at 1:59 PM, Tom Lane wrote:
> Bob Ippolito <bob(at)redivi(dot)com> writes:
>> The attributes look like the names of all the columns in the table,
>> and reindexing didn't help.
>
> So at this point it seems that the pg_class row disappeared, but there
> probably wasn't any actual DROP operation --- you'd think at least
> some
> of those other entries would have been deleted by a DROP.
>
> My next guess is that the pg_class row simply got clobbered somehow,
> eg its xmin field got set to something ridiculous. The only way I can
> think of to investigate that is to dump out the contents of pg_class
> with pg_filedump --- are you game for that? If so, get the right
> version of pg_filedump from
> http://sources.redhat.com/rhdb/utilities.html
> and run it with the -i -f options (usually produces the most helpful
> output, in my experience).
This is 8.1.0, can I use pg_dump 4.0 with that? The entire database
is 39GB, there's a way to just get pg_class, right?
-bob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2005-11-21 22:28:37 | Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach |
| Previous Message | Jim C. Nasby | 2005-11-21 22:05:07 | Re: [COMMITTERS] pgsql: make_restrictinfo() failed to attach the specified |