From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "O'Shea, Brendan" <boshea(at)akamai(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ERROR: catalog is missing 9 attribute(s) for relid 10297 |
Date: | 2008-01-04 19:02:20 |
Message-ID: | 20728.1199473340@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"O'Shea, Brendan" <boshea(at)akamai(dot)com> writes:
>> "Lane, Tom" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Ugh. Does it work if you do
>> export PGOPTIONS="--ignore_system_indexes=1"
> I tried that, but unfortunately pg_dump still fails to run and the error
> message is identical to previous attempts.
Huh. So it's not index corruption then. Table corruption is still a
possibility but it seems likely that you'd be getting other errors
during the seqscan that looks for the rows. This suggests that the rows
actually disappeared from pg_attribute, which is a bit hard to credit.
The only mechanisms I can think of are that VACUUM decided they were
dead or something physically truncated the table. The latter would
probably have zapped a lot of other rows though.
Have you checked to see if pg_roles is the only relation with this
problem? Try
select c.relname from pg_class c left join pg_attribute a
on a.attrelid = c.oid and a.attnum > 0
group by c.oid,c.relname,c.relnatts having count(*) != c.relnatts;
> Any suggestions for additional logging we might turn on to help
> determine the cause of this issue?
Maybe VACUUM VERBOSE on pg_attribute? Although you'd have to get lucky
enough to catch the time that it zapped the rows, if that's what the
problem is.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | SHARMILA JOTHIRAJAH | 2008-01-04 19:10:55 | postgres 8.3 betat 1 version download |
Previous Message | Jan Sunavec | 2008-01-04 18:49:35 | Re: tsearch2 headline options |