Re: ERROR: catalog is missing 9 attribute(s) for relid 10297
| От | Tom Lane |
|---|---|
| Тема | Re: ERROR: catalog is missing 9 attribute(s) for relid 10297 |
| Дата | |
| Msg-id | 20728.1199473340@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | ERROR: catalog is missing 9 attribute(s) for relid 10297 ("O'Shea, Brendan" <boshea@akamai.com>) |
| Ответы |
Re: ERROR: catalog is missing 9 attribute(s) for relid 10297
|
| Список | pgsql-general |
"O'Shea, Brendan" <boshea@akamai.com> writes:
>> "Lane, Tom" <tgl@sss.pgh.pa.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
В списке pgsql-general по дате отправления: