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 по дате отправления: